10 Maven Security Best Practices

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:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password
Master password:
{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}

Once created, store in your ~/.m2/settings-security.xml file as follows:

<settingsSecurity> <master>{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}</master> </settingsSecurity>

Now you’re able to create a server password by running the following command:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-password
Password:
{155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}

Store this in your settings.xml file as follows:

<server> <id>my.server</id> <username>smaple</username> <password>Simon reset this password on 2019-03-11, expires on 2019-04-11 {155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}</password> </server>

For more information, look through the maven documentation page on storing secrets in the settings.xml file.

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:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password P@ssw0rd

"10 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.

$ mvn -C install // fail if checksums don’t match

$ mvn -c install // warn if checksums don’t 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:

<properties>
  <my.property>value</my.property>
</properties>

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 authority.

<developers>
    <developer>
      <id>grander</id>
      <name>Danny Grander</name>
      <email>danny@snyk.io</email>
      <organization>Snyk</organization>
      <organizationUrl>https://snyk.io</organizationUrl>
      <roles>
        <role>security</role>
      </roles>
    </developer>
  </developers>
  ...
</project>

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!

DOWNLOAD THE CHEAT SHEET!

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.