All cheat sheets, round-ups, quick reference cards, quick reference guides and quick reference sheets in one page. Maven (Apache Maven) W. Apache Maven 2 by Matthew McCullough pdf (refcardz.dzone.com) Getting Started with Maven Repository Management by Jason Van Zyl pdf (refcardz.dzone.com). Learn all about the properties available in flexbox through simple visual examples.
Once again we’re offering you a security focused cheat sheet! This month we’re providing 10 best practices for how you can enhance your Maven-foo. Maven is the clear leader amongst build tools in the Java and JVM ecosystem. *SPOILER ALERT!* Our JVM ecosystem survey results, that will be released in October, shows Maven’s dominance continues into 2018, and doesn’t look like it’s going anywhere with six in ten developers using the build tool in their main project, as shown below.
This is Snyk’s fifth cheat sheet this year (wow, where did the time go?), having already created cheat sheets on Type Inference in Java, GitHub Security best practices, Zip Slip, and 10 Spring Boot Security Best Practices in previous months. This post was masterminded in Crete when I was laying on a beach with the Chairman of the Apache Maven project, Robert Scholte. We sat on the glorious golden sand, swam in the beautiful warm cretan waters and came up with the following 10 security tips – don’t say we never do anything for you
1. Encrypt your Secrets
Since Maven 2.1.0 it has been possible to encrypt passwords on shared build machines. When multiple users have access to a shared machine, or a settings.xml file is accessible by many users, it should have any stored secrets encrypted. If you share settings.xml files with other developers, you should consider removing secrets from the file so that only authorized users have privileges to deploy Maven artifacts to repositories rather than the entire team. These authorized users would have a settings-security.xml file stored locally within their Maven settings folder or somewhere private to that user. In the event your builds run in a shared location, used by the wider team, you should encrypt secrets in the settings.xml file. To do this you will need to create a master password that you can store and share appropriately.
You can create both the master password and server passwords using the Maven CLI by running the following command:
Once created, store in your ~/.m2/settings-security.xml file as follows:
Now you’re able to create a server password by running the following command:
Store this in your settings.xml file as follows:
For more information, look through the maven documentation page on storing secrets in the settings.xml file.
Test your Java applications for vulnerabilities
By submitting this form you consent to us emailing you occasionally about our products and services.
You can unsubscribe from emails at any time, and we will never pass your email onto third parties. Privacy Policy
2. Don’t use passwords in the CLI
In the previous example we showed the correct way to add secrets into your config files. There is also a wrong way, and we want to make sure you know this so you can avoid it! A legacy option on the CLI commands shown above is to provide a password on the command line for both encryption commands, such as the following:
While this would succeed and provide you with encrypted secrets, you should never type your secrets on a command line in plain text. These secrets are stored in the console history and are easily retrievable.
3. Always Use HTTPS
Maven repositories can be local or remote. Your local repositories, typically found in the ~/.m2/repository/ directory of your machine, are cached versions of the projects you have previously downloaded. Remote repositories could include Maven Central, or a repository your organisation has set up, using artifactory or similar. You can see which repositories you are using in your build by looking in the element of your pom.xml. As with most communication these days, it’s incredibly important to use HTTPS when connecting to third-party services, and Maven repositories are no different. Validating that you are talking with the servers you want to connect with will reduce the chances of any Man In The Middle attacks, or more specifically a Resources Downloaded over Insecure Protocol vulnerability.
To avoid this, always communicate to any repository via HTTPS, even if that repository is hosted by your own organization. To enable this, ensure your and elements in your pom.xml use https in their URLs.
4. Check Dependency Health
Pulling in third-party dependencies into our applications is extremely commonplace, and often done by developers without too much thought beyond “does it functionally do the job?”. It’s just as important that the overall health of the dependency is good enough to pull into our application. Things you should look for to ascertain the health of a project you’re considering depending on could include:
Number of active committers – Open source projects maintained by just one or two people can be risky because they tend to rely on a single individual for updates and releases. Having a team of contributors reduces this risk significantly.
Documented Security policies – Providing users with a procedure to report security issues will increase the chance that the project receives them in the first place. Equally, providing a mechanism that allows users to be notified of security issues and fixes as they arise allows users to consume dependencies in a more secure fashion.
Regular updates and releases – Make sure the projects you depend on are actively developed. First of all, it will help with the future development of your own project, as you know that your dependencies will stay up-to-date with language features etc. But from a security point of view, it’s important to know that any security issues raised will be dealt with promptly.
5. Test for Known Vulnerabilities
Attackers target open source dependencies more and more, as library reuse provides many victims for a malicious hacker who tries to exploit a known vulnerability. It’s important to ensure that there are no known vulnerabilities in the entire dependency tree of your application.
Using tools such as Snyk to test your Maven build artifacts will flag those dependencies that have known vulnerabilities. It provides you with a list of vulnerabilities that exist in the packages you’re pulling in through your pom.xml file in a dashboard.
Additionally, it will suggest remediation advice, whether through version upgrades or with patches created by the Snyk security team. If you connect your source code management tool, such as GitHub, Bitbucket or GitLab, for example, you can automatically remediate your security issues via a pull/merge request. Snyk continues to protect your environment by ensuring that any future pull/merge requests raised are automatically tested, using webhooks, to make sure other developers do not introduce new vulnerabilities into the project.
Snyk is available via a web UI as well as a CLI, so you can easily integrate it with your CI environment, and configure it to break your Maven build when vulnerabilities exist with a severity beyond your configured threshold.
You can use Snyk for free for open source projects or for private projects with a limited number of monthly tests.
6. Test your Checksums
A checksum is designed to detect errors which may have been introduced during data transmission or storage. It is important you check your dependency checksums for each of your project dependencies. Checksums are often used to verify data integrity and while they should not be relied upon to verify the authenticity of your dependencies, it’s an extra check that helps. In Maven 4, testing the checksums of every dependency will be done by default, however before then, use the -C flag on your Maven commands to enable checksum testing that will fail a build should the checksums not match.
7. Don’t use Properties for Passwords
Properties are commonly used in Maven to act as placeholders in pom.xml files. You can set a property, which we’ll call my.property in the pom.xml file example below:
The my.property property can now be referenced anywhere in that pom.xml file by using the ${my.property} notation. While this is a very useful feature, it makes it very easy to store passwords for use elsewhere. However, by doing so, we are of course storing passwords in plain text and potentially sharing across a team. Plugins should be encouraged to use server-entries from your settings.xml
8. Use Maven developers/roles
As the State of Open Source Security report showed, it’s important to provide people with the information they need should they find a security issue that requires reporting. GitHub repositories that contain a security disclosure process are over three times more likely to receive security bug reports than repositories without a documented disclosure process.
In the Maven pom.xml file, you can add a developers tag that contains information about security contacts should anyone need to contact someone on your team regarding a security issue. This can be seen below, where I add Danny, our in-house security sensei.
Preferably, you can point the email address to a more generic security@yourdomain.com, so that if anything were to happen to the security contact, the email will still reach a monitored inbox.
9. Stay up-to-date
As always, security updates arrive in newer versions, so try to keep up to date with Maven releases. This will reduce the chances of working with a version containing a security flaw. In particular, stay away from Maven 3.0.4, as it contains a critical security issue that ignores certificates for HTTPS connections. For the most up to date Maven version, head to the Maven download page.
10. Check Security Bulletins
The Maven team updates you on any security issues via security bulletins on the Apache Maven site. When the Snyk security team recently found many instances of the Zip Slip vulnerability, the Apache team (who worked extremely hard with us to eliminate instances of Zip Slip in Apache projects) issued a bulletin on the Apache Maven site below:
Be sure to sign up to the announce@maven.apache.org mailing list and/or follow @ASFMavenProject on Twitter to hear about the latest news from the Apache Maven project.
That concludes our 10 security best practices for Apache Maven. Be sure to download this cheat sheet and pin it up somewhere nearby so that you’re always thinking about security in your builds!
Be sure to print out the cheat sheet and pin it up somewhere to remind you of some of the best practices you should follow if you’re a developer using Maven.
Maven is a build automation management tool in java projects. Most of the people working on java related technologies know about the maven usage. I am listing down the list of Maven commands with examples reference which is very helpful for developer. This list can be used by all the Java developers for their daily usage in projects.
Please have a look of my previous article maven installation. For the maven installation, the JDK is required.
Listing down all the maven command tutorial at a high level.
- How to create a sample maven standalone project
- Creating a sample web standalone project
- Clean project
- Compile project
- Building web apps
- Deploy project
- Run unit and integration tests
- Ignore test execution
- Generate java documentation for the project
- Maven debug
- dependency tree and download
- maven profiles
- Generate site
Creating a maven standalone project
This is the starting step for any Java project to create. This command runs at the command prompt and creates a project with project name i.e. artifact id. This project is located in group “org.cloudhadoop” using groupid,.
After running this command for the first time, this tries to download all the required artifacts downloaded from remote repositories ( from maven .. etc) and copy to your local repository and after that, it creates a project. This project contains the src/main/java and src/test/java folders which contain the HelloWorld java program in the main folder and test class for hell0world program in the test folder.
Creating a web standalone project
As you know target folder contains all your compiled classes, as well as the jar, war files when you run the project with maven install.
Clean is maven predefined goal, this command deletes all the contents in the target folder.
compile maven project
compile is maven predefined goal, this command compiles all your java classes which include src files as well as text files in your project.
Build web apps
maven package goal is used to build maven applications.
As you know any Java project can be packed as jar or war.
The package is a maven predefined goal. By giving this command, first, compile all the java files(using compile goal) and run all your test classes and copy all these files to target folder and create a jar, war file. The final output for this command is jar/war of your project located in the target folder.
Deploy/install project
When we run this command under your project, it will do all the tasks in “mvn package” and create the required jar/war file in target folder.
Maven install goal is used to deploy the project(jar/war) to the local repository. and local repository location is /.m2/repositories/groupid/.
Maven deploy goal is used to deploy the project to the remote repository like the nexus. so that other developers can use this artifact in their module. remote repository location is specified in pom.xml.
Run unit and integration tests
Test goal is used to run only the test classes in your project. The test files are located under src/test/java and copy the result to your target/test-classes, target/reports if any.
Ignore test execution
In 4#, with maven package command run, tests are also executed. If you want to skip the unit tests, The we can use this command. You can use this option with install goal also.
Generate java documentation for the project
This will generate java documentation for your project. And the generated java doc report can be found in the target folder
This will includes API documentation for your Java classes in your project.
Debug Maven
This command is used to start the maven goals in debug mode and gives logging information. This command gives more information like what artifact is failing for what reason.
This command can be used when you are not getting any clue for your maven project execution failure.
dependency commands
We have many command to list out depedency tree which tells about direct and indirect depedencies of an maven project.
There is also an command to download all depedencies without doing anything
to download specific artifact depedency, we have to provide group, artifact id and version as given below.
maven profiles
Maven provides the specific profiles based on user/environment and global
Suppose your project wants different settings for Production and Development.
Jrebel Maven Cheat Sheet
You can define the profiles in pom.xml
You can configure environment properties in each profile, This will be actived with command line option -D.
The same can be activated with following commands
For production
Maven-jaxb2-plugin Cheat Sheet
For running with development configuration
Generate site
Maven Cheat Sheet Pdf
The predefined goal in maven is used to generate site documentation in formatted style.
Apache Maven Cheat Sheet
Please let me know if you like my post and share your comments.