A new CVE has been published for the recent Apache Santuario - XML Security for Java releases (4.0.0, 3.0.3, 2.3.4 and 2.2.6):
"A private key may be disclosed in log files when generating an XML Signature and logging with debug level is enabled. Users are recommended to upgrade to version 2.2.6, 2.3.4, or 3.0.3, which fixes this issue."
Software Bill of Materials (SBOMs) are a recent hot topic, in part due to an executive order by the US government which references making an SBOM available on a public site. Making a signed SBOM available publicly allows downstream projects to consume the SBOM automatically using tooling to list dependency names and versions, what licenses they use, what vulnerabilities are known about them, etc.
When looking at a recent Apache commons-codec version in Maven Central recently, I noticed that it was publishing signed SBOMs in both CycloneDX and SPDX formats. Inspired by this, I've started to add similar functionality to the other ASF projects I contribute to, starting at first with CycloneDX support. It's very easy to do this for Java-based projects by just adding Maven plugins, see for example.
Last month, version 4.0.0-M1 of the Apache XML Security for Java library was released. The SBOM is available on Maven Central along with the released artifacts.
Let's see what we can do with this SBOM by hand. Firstly let's download it and the signature:
Validate the signature (using the KEYS file):
Now we're ready to answer some questions about the library.
What library name, versions and licenses are third-party dependencies of Apache XML Security for Java 4.0.0-M1? We can extract this information using the jq tool and some hacking:
Next we might want to know if any of these dependencies have publicly known vulnerabilities. For this we can use the excellent Grype tool, which parses the sbom directly:
For now at least, it outputs that no vulnerabilities were found. So by using the SBOM with some third-party open-source tools we can find out what the third-party dependencies are, re-assure ourselves that they are available under a business-friendly open-source license, and ensure that there are no known vulnerabilities associated with them. Hopefully more open-source projects will roll-out having publicly available SBOMs for their releases to make answering these questions easier.
Software Composition Analysis (SCA) is the process of figuring out which third-party dependencies are used in your project. It's an essential part of the software security process as it helps you to answer questions like:
In this post we'll look at some popular open-source SCA options. It's not intended to be comprehensive, let me know if I missed anything! Adding one or more of these projects to your CI/CD process will really improve your Supply Chain Security process.
If your project is hosted on GitHub, then the first port of call for SCA is to enable GitHub Dependabot. You have the options to just enable alerts, which let you know if your dependencies have known CVEs, and also to have Dependabot automatically create pull requests to upgrade the dependencies in question to fix the vulnerability. Adding CI using GitHub Actions to this process to verify that the updates don't break any of the tests/build means fixing CVEs is a straightforward process. Dependabot has support for a wide range of software ecosystems.
GitHub recently added support as well to download an SPDX SBOM for a GitHub repository via e.g for Apache CXF https://github.com/apache/cxf/dependency-graph/sbom.
OWASP Dependency-Check is another tool that can help you find CVEs in your dependencies. It's useful as an alternative to dependabot if you don't have access to the security tab of a GitHub project, or if Dependabot is otherwise not enabled. You can run it on a Maven project via:
Aqua Trivy is a really useful tool for SCA as it can help with a wide range of scenarios:
Anchore Syft is a tool which can help you with generating an SBOM from an image or filesystem:
Anchore Grype is another super-useful tool that works well with Syft:
Yet another tool is Google's OSV-Scanner:
In the previous blog post, I looked at how to use OpenSSF Scorecard to improve the security posture of your open-source GitHub projects. This is a really useful tool when working at the level of individual repositories. However, what if you want to apply security policies to many repositories in a GitHub organization? This is where OpenSSF Allstar comes in.
Detailed installation instructions are available here. The easiest way of getting started is to install the OpenSSF AllStar GitHub app in your organization. However you may not wish to grant access to your internal/private repositories to this instance, in which case it's pretty easy to manually install it.
Allstar reads configuration from a GitHub repo called ".allstar" in your GitHub organization. Here an "allstar.yaml" file defines the general configuration for the tool, e.g.:
This configuration uses the "Opt out" strategy, meaning that all repositories are included in the organization unless you explicitly opt them out. Archived and forked repos are excluded as you may not care about applying security policies to these types of repositories. Finally the configuration blocks individual repositories overriding the allstar configuration.
Allstar policies are added by checking in the corresponding yaml file to the .allstar repository. Each policy allows you to define whether to just log the issue or whether to create a GitHub issue for it in the repository where a policy violation was found. GitHub issues are labelled with "allstar", making it easy to search for them across all repositories in your organization.
Here are some of the policies Allstar currently supports:
I've found allstar pretty useful and submitted a few contributions to it in the spirit of open-source, that were included in the recent v3.0 release:
OpenSSF Scorecard is a tool that assesses your project against a number of security best practices and assigns a score (out of 10). It is a really useful thing to run on any open-source project you might contribute to, to try to improve the overall security posture of the project, or even to assess how secure a third-party project is that you might want to use. In this post I'll describe how I improved the security posture of a number of ASF projects I contribute to using OpenSSF Scorecard.
The first step is to install the OpenSSF Scorecard GitHub Action. This can be done in the GitHub dashboard, by going to "Actions", then "New Workflow" and searching for "OpenSSF Scorecard". Once this is committed to source control and runs successfully, the findings appear in the GitHub dashboard under "Security" and then "Code scanning". After the first run, you can add a Scorecard badge to the README of your project to display the current score. For example, for Apache Santuario.
After doing the initial run to get the base score, it's time to try to improve the score a bit. Here are some of the actions I performed:
Here are some of the ASF projects I applied the above to, and their current OpenSSF Scorecard result at the time of writing:
Future improvements that would improve the score are as follows:
