Monthly Archives: May 2014

Enforce Dependency Management Policies with the Maven Dependency Plugin

A non-trivial application will typically rely on a multitude of libraries to provide basic functions. The complexity of such “dependencies” ranges anywhere from functions for basic datastructure manipulation to fully-featured socket server implementations. Much of this code is provided by third parties, and conveniently made available to build systems through large (public) repository servers like Maven Central.

In an application that is using these dependencies, third party code will ultimately handle user provided input. This opens up questions around security and policy compliance. As an example, an organization may want to ensure that dependencies with known security vulnerabilities are not being used in production code. There might also be dependencies that are only available under very restrictive license terms (e.g. GPL), and using them e.g. in a closed source product may be a policy violation. Further examples for policy violations may include governmental restrictions, such as export restrictions.

The Maven Dependency Plugin allows creating a project’s “dependency tree”, that is, a list of all direct and indirect (“transitive”) dependencies of a project. This tree can be stored in a text file for every module in a multi-module Maven build, and then be processed in a post-build step to scan, for example, for policy compliance of the presence / absence of specific versions of well-defined dependencies.

 

Specifying all dependencies in Maven’s DependencyManagement sections, preferably in a dedicated / high level (e.g. root) POM file ensures that all modules of a Maven project use the same version of a specific dependency. This greatly simplifies dependency management in a project, because there is no risk of contradicting dependency specifications. In particular when updating a dependency in a sub module, using Maven’s DependencyManagement sections makes it unnecessary to update that same dependency in a different (possible seldom changed) sub-module of the same project. Note that it is possible to have a DependencyManagement section in every PMO file, augmenting each other as the build progresses a project’s modules from the root to the leaves. This allows having multiple versions of the same dependency in a project if such a configuration would be required for valid reasons – and at the same time forces that such a decision is consciously made and explicitly documented in the POM files by creating appropriate entries in the various DependencyManagement sections.

 

The configuration example below shows how the Maven Dependency Plugin can be used to enforce that all dependency versions must be specified in a DependencyManagement section, and at the same time create a text file for each sub module with a fully qualified list (group ID, artifact ID, version, scope) of all direct and transitive module dependencies.

<build>
  ...
  <plugins>
    ...
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-dependency-plugin</artifactId>
      <version>${mavenDependencyPluginVersion}</version>
      <executions>
        <execution>
          <id>dep-resolve</id>
          <phase>validate</phase>
          <goals>
            <goal>resolve</goal>
          </goals>
          <configuration>
            <excludeTransitive>false</excludeTransitive>
            <outputFile>${project.build.directory}/dep_current.txt</outputFile>
          </configuration>
        </execution>
        <execution>
          <id>analyze-dep-mgt</id>
          <phase>validate</phase>
          <goals>
            <goal>analyze-dep-mgt</goal>
          </goals>
          <configuration>
            <failBuild>true</failBuild>
            <ignoreDirect>false</ignoreDirect>
          </configuration>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
  ...
</build>

Edit:See https://github.com/mbeiter/util for an example on how to configure the Maven Dependency Plugin as described in this post for a multi-module build.

(Security) Static Code Analysis in Maven Builds

Automating static code analysis is key to making static code analysis a useful tool for application security. Maven is a very powerful build management tool, and in combination with tools provided by the community, greatly helps to define and enforce static code analysis rules. Maven comes with an integrated versioning mechanism of the build configuration, which makes it an ideal tool to enforce a static code analysis strategy in an auditable fashion – not only for Java projects!

The table below gives an overview of how Maven can be used to support static code analysis. There are of course many alternatives, but the following plugins are what I commonly recommend for the projects I am working with.

The Maven Compiler Plugin and the POM file configuration enforces compiler settings and options.

The Maven Dependency Plugin, the Maven Checkstyle Plugin, the Maven PMD Plugin, and the Findbugs Maven Plugin can be configured to:

  • Enforce code conventions (formatting, whitespace, naming, …)
  • Find unsafe functions as well as unsafe or incorrect use of functions, and provide recommendations of safer alternatives (e.g. for concurrency)
  • Enforce API design best practices
  • Enforce coding best practices
  • Set a standard and enforce proper creation of documentation, such as Javadocs

While proper API documentation is not always considered part of security, it is very helpful for auditors when doing code reviews / security audits, which is why I always include code documentation.

The Maven plugins mentioned above are all open source and available free of charge. However, there are also commercial options available. For example, with their Fortify toolkit HP provides an excellent static code analysis tools, and The Fortify plugin for Maven (which is part of the standard Fortify distribution) can be configured for direct automated integration of Fortify into the Maven build.

Security Static Code Analysis

Security static code analysis is performed together with other static code analysis methods at or before compilation time. The biggest advantage of using static code analysis tools is that they can be used in the very early stages of the projects, long before the code has reached a state where it can be executed and evaluated with traditional quality assurance methods. With the high level of automation that can be achieved, static code analysis is an ideal tool to introduce a minimum code quality level without wasting the precious time of security experts on routine manual reviews. Common automation options in particular include automated execution of code auditing at check-in to SCM, as well as automated failing of a build in centralized build environments (e.g. when using CI systems such as Jenkins).

Static code analysis tools cover a broad range of code analytics options, ranging from trivial pattern matching tools to find comments in the code like “todo” or “fixme”, up to very complex execution path analysis tools. Such advanced tools can observe, for example, a specific variable through the execution path of a method and make deductions on the reliability and sanitation status of data stored in such variables.

Depending on the policies of the organizations and products, any form of static code analysis may be security relevant. While it is common understanding that execution path analysis often provides valuable insights on security, some organizations may decide that enforcing specific code formatting is relevant to their security program. One justifications for this is that a common definition of whitespace across the project’s developer community makes semi-automated code reviews easier.

For these reasons, static code analysis is mostly policy driven, and the (secure) coding policies that an organization defines ultimately drives the selection of tools and their configuration. Consequently, the selection of approved tools and their (project specific) configuration is key in making static code analysis a significant contributing factor to application security. As with any policy, the static code analysis rule set, as well as the list of approved tools need periodic reviews to make sure that the latest advances in security research and subsequent tool improvements are incorporated into a project’s security strategy.