Maven is the most commonly used build system in the Java ecosystem, and it has been for many years. Building your application with Maven is easy since it takes care of many things for you. In different phases of the Maven lifecycle, it handles things like: With Maven, the development lifecycle happens the same way on every machine for every developer on the team, as well as within the CI pipeline.
Nowadays, developers are responsible for more than just creating the application. Besides working on features, developers have to focus on their applications’ maintainability, scalability, reliability, and security. Many developers are unsure of where to start with security. In addition, most companies still work with a dedicated security team instead of having security expertise inside the team. A lot of developers practically live in their integrated development environment (IDE).
This is the eighth entry in the blog series on using Java Cryptography securely. The first few entries talked about architectural details, Cryptographically Secure Random Number Generators, encryption/decryption, and message digests. Later we looked at What’s New in the latest Java version. All of this equipped us to talk in detail about some of the most common Cryptographic applications. We started by looking at the symmetric cryptography-based application with Message Authentication Code.
YAML is a human-readable language to serialize data that’s commonly used for config files. The word YAML is an acronym for “YAML ain’t a markup language” and was first released in 2001. You can compare YAML to JSON or XML as all of them are text-based structured formats. While similar to those languages, YAML is designed to be more readable than JSON and less verbose than XML.
The Spring MVC framework is a well-known Java framework to build interactive web applications. It implements the Model-View-Controller architecture pattern to separate the different aspects of your application. Separating the different logic elements like representation logic, input logic, and business logic is generally considered good architectural practice.
Java configuration is everywhere. With all the application frameworks that the Java ecosystem has, proper configuration is something that is overlooked easily. However, thinking about Java configuration can also end up in a security issue if it is done in the wrong way. We call this misconfiguration. Security misconfiguration is part of the infamous OWASP top 10 vulnerability list and has a prominent spot on place 6.
This is the seventh entry in this blog series on using Java Cryptography securely. Starting from the basics we began diving deeper into various basic cryptographic primitives such as Cryptographically Secure Random Number Generator, symmetric & asymmetric encryption/decryption & hashes. After taking a brief interval, we caught-up with cryptographic updates in the latest Java version. Skip to the TL; DR
So, you want to build a Java application and run it inside a Docker image? Wouldn’t it be awesome if you knew what best practices to follow when building a Java container with Docker? Let me help you out with this one! In the following cheatsheet, I will provide you with best practices to build a production-grade Java container. In the Java container example, I build using these guidelines, I will focus on creating an optimized secure Java container for your application.
Every Java developer should follow coding standards and best practices to develop secure Java code. It is critical your code is not vulnerable to exploits or malicious attacks. In recent times, even big organizations like eBay, the CIA, and the IRS have fallen victim to vulnerabilities in their applications that have been discovered and exploited by attackers. The following guidelines provide a solid foundation for writing secure Java code and applications.
Imagine you are a Java programmer and that you just decided you want to use Snyk Open Source scanning to help you find security problems in your third party libraries. Good call! However, after connecting your repository to the Snyk Open Source scanner, you find out that you have ten or maybe even 50 vulnerabilities in the packages you depend on. The major question is: where do I start?
