What can go wrong with a tool that just logs messages to a text-based file? Nothing right? That is what virtually every organization on the planet must have been thinking because they all use log4j. Of course, the reality is proving us all wrong. Suddenly on December 11, 2021, we were all exposed to the log4j vulnerability, and your organization could have been (might have been?) breached!
Log4j Vulnerability Explained
Log4j is an extremely popular and heavily used open-source Java library that can be used for unauthenticated remote code execution, making CVE-2021-44228 and CVE-2021-45046 critical vulnerabilities that you must pay attention to.
In other words: if your software uses this library, then there is a good chance that anyone can gain full remote control of your servers and data.
The log4j vulnerability is among the worst we’ve seen in the last 5 years, in part because the vulnerability itself is so severe and so easy to trigger. Adding to the severity, this vulnerable library is among the most popular and widely deployed open-source Java libraries on the planet.
Differences between log4j vulnerability versions?
The Apache Struts disaster from 2017 (CVE-2017-5638) was a large part of why we launched our startup (mergebase.com): to help companies protect themselves from known vulnerabilities in open source libraries exactly like these.
This time it’s even worse. Globally, everyone must now urgently scramble to upgrade all applicable software to use Java library log4j version at least 2.15.0 (which was published today). Companies that for whatever reason fail to execute this upgrade will likely be attacked and exploited within the next few days – assuming they are not already under attack.
We cannot stress how urgent it is for administrators of Java systems to succeed in rolling out this upgrade. Patch this Critical log4j vulnerability in Java CVE-2021-44228 immediately.
How can you check for vulnerabilities?
There is an easy way to check any server for the log4j vulnerability. At the root of your file system, using an administrator account, download and run our free Log4J-Detector tool: https://github.com/mergebase/log4j-detector
This command can take several hours to complete. Any occurrence of “_VULNERABLE_” in this command’s output indicates with high probability that you are vulnerable to this severe software exploit.
MergeBase can help you patch your vulnerable systems to eliminate this bug and help you in situations where patching is not possible. We have a patented cyber-security technique for exactly this situation.
You can try MergeBase to see if you are vulnerable, or download our free tool to detect vulnerable log4j versions on any of your machines and in any application.
Real-world supply chains can involve planes, ocean freighters, trains, trucks, and even bike couriers. So it’s no surprise that software supply chains also involve a wide variety of complementary production, distribution, and deployment channels.
One of the challenges with securing software supply chains is that solutions must be combined to address each conduit supporting the entire chain. Patching the libraries your software engineers copied into your final build is insufficient—you must also consider your base images, the packages and platforms brought in via provisioning scripts, and even possibly plugins deployed by admins post-deployment!
Unfortunately, these disparate channels often have different weaknesses and vulnerabilities and require different security approaches.
Watch this webinar with our special guest speaker and expert in open-source software ecosystems, John Speed Meyers, and the vulnerability scanning implementor, Julius Musseau, as they discuss the important perspectives on software supply chains.
What they will go through:
An understanding of today’s sophisticated and multi-channel software supply chains
What are the risks, and how to manage them
Software Supply chains security best practices
Take a look at the big picture and discuss specific techniques tailored to protect some of these critical pieces better.
Open Source Research
A lot of people will claim that open source is everywhere, but how much open source software is actually out there? In this paper, we propose a methodology and associated tool that can analyze Java binaries and determine the proportion of open source that comprises them. The result of our research shows that around 80 to 90% of the software is made from open source.
Ready to start to mitigate risks in your software supply chains?
The software bill of materials (SBOM) is a document that lists all the components and subcomponents of your software code. Some regulated industries require these documents as part of their software supply chain security efforts, and as third-party liability policies emerge, SBOMs are becoming a popular defense in the fight against cyber threats.
Much of this crime involves exploiting third-party vulnerabilities: instead of outright hacking governments and enterprise organizations, hackers target the smaller code libraries that these larger entities license or build their applications upon. Because of this, governments are imposing new regulations to secure the software supply chain in certain critical industries.
Perhaps the most notable example of this is US President Biden’s 2021 executive order calling for heightened software supply chain security. This order includes the need for software vendors to provide key purchasers with a software bill of materials.
The SBOM is a relatively new concept, and practices haven’t become normalized yet. Because of this, we’ve put together a guide to help you understand what an SBOM is, what it’s for, and how to use it—whether you’re a software vendor or a customer.
NOTE: In addition to being an advanced SCA solution, MergeBase can help you produce and verify SBOM documents. If you’re not already using MergeBase, book a demo with us to see how we can help you secure your software supply chain today!
That’s because we know that in order to secure the software supply chain, both vendors and customers need to understand the components of the software applications they’re buying and selling. At the bare minimum, a software bill of materials should include a list of every third-party code library you implement in your application. To use the CISA’s “list of ingredients” metaphor, your software bill of materials should at least mention everything that you can “buy off the shelf”—or download for free, in the case of open source components.
What does a minimum-viable SBOM include?
The US National Telecommunications and Information Administration (NTIA) lays out the required baseline attributes that a software bill of materials must entail, including information on third-party code as well as metadata on the SBOM itself.
Required SBOM metadata
Your SBOM should include the following attributes describing itself:
Author name: This is the person responsible for compiling the SBOM.
Timestamp: This marks when the SBOM was published.
Required third-party code attributes
Your SBOM should list all the third-party software you’ve built your application on, whether it’s paid or open source. For each of these software components, your SBOM should include:
Component name: This is the name of the third-party code package as specified by the supplier.
Supplier name: This credits the organization that supplied the third-party code (unless it’s already covered by the component name attribute).
Version string: This specifies which version of this third-party library you’re using.
Component relationship: This describes how the component fits into the entire SBOM. Your application has the “primary” relationship type, while the third-party components will have the “included in” relationship type. (Components may be included in other components.)
Unique identifiers: This provides any information that further identifies the component, helping your SBOM readers look up the component in relevant databases.
Commonly used SBOM formats
As of September 2021, SPDX is an internationally recognized ISO standard for creating software bills of materials, and the format is widely supported in the world of software supply chain security.
In addition, CycloneDX (from OWASP) is often used by organizations whose operations involve SBOM generation and consumption. Some organizations prefer CycloneDX for its specificity, which makes it much easier for machines to read SBOMs in CycloneDX—while others prefer the more generally accepted SPDX standard.
How SBOMs help software supply chain security efforts
A comprehensive software bill of materials brings a host of benefits to both customers and vendors. By creating this document (and keeping it up to date), you can improve how you manage your software supply chain, vulnerabilities, sales, procurement, and quality assurance.
When done well, an SBOM creates a shared understanding between customers and vendors, allowing both parties to respond to vulnerabilities together quickly.
Software customers benefit from transparency
Because an SBOM lists all the ingredients in a vendor’s application, customers can streamline their due diligence processes when selecting a vendor. Customers can compare SBOMs, check for vulnerabilities using the right software composition analysis (SCA) tool, and better manage risks involved in selecting vendors.
A good SBOM also allows customers to more easily stay compliant with software supply chain security regulations. The transparency provided in an SBOM means that customers can monitor their vendors’ SBOMs with their own SCA tools, making it much easier for them to know when they’re vulnerable.
Furthermore, an SBOM gives customers more focus when patching vulnerabilities. Because their security teams have a well-defined set of components to keep secure, they can more easily stay focused on patching known vulnerabilities.
Software vendors can streamline enterprise sales
As regulations surrounding software supply chain security come into play, software companies will face more and more compliance barriers when selling to regulated entities (or even when selling to companies who feed into regulated entities). Sales conversations with enterprise prospects will always involve some security concerns, and having an SBOM ready to present can cut down on valuable sales time—either by proving that you’re a compliant vendor sooner or by surfacing a dealbreaker early in the conversation.
Make a list of third-party components implemented in your software. Your primary source of information for this step will be your own engineering team—but you can also use a software composition analysis (SCA) tool like MergeBase to generate this list.
Gather the information required to fill out the baseline attributes listed above.
Import this component data into a structured SBOM format.
Validate the SBOM: check that the format works and all the information is correctly structured.
(Optional) Publish your SBOM so your customers and salespeople can reference it.
Remember: You will need an SBOM for each version of your product—and every time you update one of your components, you will also need to update your SBOM.
How to obtain an SBOM from a vendor
If you’re required to obtain an SBOM from a vendor (or a hopeful vendor), you will need to follow these steps:
Request an up-to-date SBOM from your vendor. Your vendor may have this publicly available, but it’s always good to double-check that you’re dealing with the correct SBOM for the application you’re using.
Verify that SBOM using your SCA tool—our customers tell us that MergeBase is especially useful for double-checking this!
Remember: A single vendor may be managing many SBOMs. Not only does each software version require its own SBOM, but any custom builds will require their own SBOMs as well. A single vendor may have multiple SBOMs for the same product—and if they’re working with a large enterprise organization, they might even need several SBOMs for the same customer.
How to consume SBOMs in any format
As we’ve mentioned, the discipline of generating and consuming SBOMs is still immature. This means consuming SBOMs is a bit difficult today—most SBOM readers can only consume these documents if they were generated within the same system.
If you’re a software customer, we recommend using a system-agnostic SBOM reader. This will allow you to ingest SBOMs no matter what tool generated them. You could use a standalone reader, but an advanced SCA will take care of this for you.
(And yes, MergeBase is a system-agnostic reader: one of the benefits of using our SCA is that you can also consume SBOMs from any generator using the CycloneDX format!)
Common software supply chain security concerns about SBOMs
Supply chain security regulations will make SBOMs a norm in regulated industries—but because this is a new discipline, it’s understandable that some vendors have raised concerns about generating and publishing them. However, the prevailing belief is that the benefits of a good SBOM far outweigh the risks.
We’ve listed a few commonly voiced concerns people have regarding software bills of materials below, as well as our thoughts on how to address these concerns. If these concerns come up in supply chain security conversations at work, these responses can help put the concerned parties at ease.
“An SBOM will tell hackers exactly where to attack us!”
Third-party vulnerabilities are the easiest way for hackers to infiltrate your otherwise secure system. Because an SBOM lists every single component and subcomponent used in your software, some are concerned that cyber criminals will simply target the weakest links in the supply chain.
However, most of the cybersecurity community agrees that the transparency an SBOM provides raises the accountability for both customers and vendors. Once a vulnerability is known, the whole supply chain can quickly patch it.
This level of transparency also incentivises vendors to source third-party code from the most secure suppliers they can, which in turn motivates the producers of subcomponents and sub-subcomponents to increase their own levels of security.
As an analogy, imagine an application is like a bank, and an SBOM is like a blueprint. While a blueprint might make it easier for a team of thieves to pull off a daring heist, it will also make it much easier for the bank’s security team to keep the vault safe: they know which parts of the building are most vulnerable, and they can allocate their security resources accordingly.
“An SBOM will give away our trade secrets!”
Just like a prize-winning baker wouldn’t want to give away her secret chocolate chip cookie recipe, some software vendors wince at the idea of publishing their own list of ingredients. However, if your software truly is an original work, this shouldn’t be an issue.
Sharing your list of ingredients shouldn’t be the same as sharing your recipe. An SBOM doesn’t display your proprietary code, and it doesn’t detail how your third-party code is implemented within your application. Unless your application is just a reskin of several other companies’ products with no added value, you should have nothing to worry about on this front.
“An SBOM will take too much time and effort to maintain!”
Making an SBOM once is easy. Keeping your SBOMs up to date and organized can get complicated, however. This will take extra time.
However, generating and maintaining SBOMs is preventive work. Flossing your teeth takes a little extra time out of each day. Changing your car’s oil takes a few hours out of each year. But compared to the costs and pains associated with a root canal or an engine failure, the benefits outweigh the costs. Similarly, the time it takes to keep your SBOMs current shouldn’t come anywhere close to the costs of time, damages, and loss of trust associated with an otherwise avoidable breach.
We recommend simply making SBOM generation and maintenance part of your routine: product development teams should include an SBOM as an artifact with every new build. It might take a little while to get used to this practice, but in the end, it will be worth it.
(This becomes very easy using MergeBase. You can generate a current SBOM document with the click of a button from our home screen. Plus, our command line tool allows you to automate SBOM production—which means MergeBase can automatically generate a new SBOM for you with every update!)
Create and verify SBOMs with MergeBase
As governments and industries increase software supply chain security, software bills of material will become more and more common. It’s smart to get ahead of the game and begin learning to create and consume SBOMs now. A great place to get started is the NTIA’s SBOM resource library: this includes how-to guides, explainer whitepapers, and even a few use cases for reference.
If you’re already a MergeBase customer, you can use our tools to generate your own SBOMs automatically—or import and export your suppliers’ SBOMs, even if you don’t have access to their code.
If you’re not a current MergeBase customer, consider exploring the ways we can help you increase security against third-party vulnerabilities. We offer a full software composition analysis (SCA) suite that monitors your code libraries for known vulnerabilities, automatically detects and implements patches, and both generates and consumes SBOM documents.
If you want to increase your software supply chain security, book a demo with us today and we’ll show you how it works!
Ant was Java’s original build system. Ant was developed internally at Sun Microsystems around 2000 to help build the original Tomcat JSP server. I vaguely recall learning many years ago that James Duncan Davidson and Jason Hunter (now of JDOM fame) were the main culprits behind Ant. Of course, we’re now in 2022, and Ant has long since been replaced with Maven. But from 2000 to 2010, Ant was very popular. Even today, many projects, especially internal corporate Java projects, still use Ant. Why fix something when it’s not broken, right? Unfortunately, important application security tools for SBOM generation and known-vulnerability scanning currently don’t work with Ant. But MergeBase does!
Scanning Ant-Based Java Projects With MergeBase
Unlike Maven, Ant does not include any built-in dependency resolving and downloading. With Ant-based projects, developers are their own when it comes to specifying and retrieving important re-usable libraries required to build and deploy their software systems. Because it’s up to developers, there’s a huge mishmash of approaches and traditions across the Ant universe – it’s a total free-for-all! (Maven was designed from the ground-up mainly to solve this pain and chaos). Nonetheless, there is one constant we can count on: when Ant is finished building a software system, the end-result will be a deployable runnable Java software artifact, including all of its required libraries. MergeBase leverages this fact to achieve a reliable “post-build” known-vulnerability SCA scanning solution for Ant projects.
MergeBase uses a powerful signature-based matching algorithm to accurately identify Java dependencies. Unlike binary fingerprints (like SHA-2 or MD5), our matching algorithm is stable in the face of typical library permutations (e.g., cryptographically signed vs. unsigned libraries, compiler variations, and even different timestamps in zip-file metadata). Our matching algorithm is also able to find versions “between” versions – for example if your developer decided to grab a pre-release version of Apache Commons HttpClient 3.0 directly from “trunk” and threw that into your Ant lib directory, MergeBase’s library-identification logic can handle that.
Competing Scanners vs. Ant
Most competing scanners are not able to scan Ant-based Java projects. They exit with error messages like these:
“Could not detect supported target files”
“Detected supported file(s) in ‘.’, but there was a problem generating a dep-graph.”
“No dependencies were identified”
This is because existing commercial scanners probe projects build scripts for dependency coordinates. Of course, MergeBase is happy to operate in this mode as well when it’s available, but we also offer a pure “files-on-disk” mode of scanning. Philosophically, we believe a “files-on-disk” scan mode is critical because that gives you the ground-truth: the actual libraries included in your application’s deployment! Of course, your Maven pom.xml scripts and NPM project.json files and yarn.lock files say useful, interesting things about your system’s dependency graphs, but there’s nothing stopping post-build processes from further adjusting the deployment context by deleting, transforming, copying, or even downloading additional dependencies outside of normal build processes.
Turns out our “files-on-disk” philosophy is also perfect for Ant-based Java projects. When an Ant-based application is finished building, all of its dependencies will be packaged up for deployment. A powerful signature-based scanner like MergeBase can then figure out exactly which Maven-coordinates correspond to each of these files.
Of course, Ant projects don’t use Maven-coordinates, but the industry has now standardised around these (e.g., see: PURLs). Known-vulnerability reports and SBOM exports are expected to refer to Maven-Central dependency coordinates. Fortunately, MergeBase is able to accurately map the random Jar files sitting across various “lib/” directories in an Ant-based Java project back to Maven-coordinates. Thanks to these Maven-coordinates, MergeBase can then determine the known-vulnerabilities in your libraries that you need to be aware of, as well as giving you any SBOM reports (in CycloneDX or SPDX formats) you might also need to comply with current software engineering standards.
Using MergeBase To Scan Ant Projects
In this section, we’ll show you explicitly how you can use MergeBase to scan Ant-based Java projects.
First, make sure your Ant project successfully builds! Once your Ant build completes, you can now run MergeBase. When scanning Ant projects, we recommend using MergeBase’s “–binary” and “–all” flags. This way, even zips inside zips and jars inside wars will be examined.
Simply add the “–sbom” flag to the “java -jar mergebase.jar” command above. Alternatively, you can also download the SBOM report directly from your MergeBase dashboard. All MergeBase scans are also stored in your MergeBase dashboard to help keep you up-to-date in case any new vulnerabilities are discovered in between scans.
A Quick Scanner Bake-Off
We have put together a small buildable Ant-based Java project for anyone who would like to play with competing scanners. You can download this project here. It’s an old Apache-2.0 licensed Java open-source project I created in 2006!
1. Download it and unzip it. 2. cd ./not-yet-commons-ssl-0.3.17 3. ant clean 4. ant all
Scanning It With MergeBase:
Take a free MergeBase trial, and then download the “mergebase.jar” CLT. Run the following command in the “./not-yet-commons-ssl-0.3.17/” directory (after building it first!):
$ java -jar mergebase.jar –binary –all .
The resulting output is the same as above (24 vulnerabilities found circa September 2022). Of course that will change as more vulnerabilities are discovered with each passing year!
Snyk? “There was a problem”
Snyk does not appear able to scan this project:
$ snyk test --scan-all-unmanaged .
Failed to get maven dependency for './not-yet-commons-ssl-0.3.17.jar'. No package found querying 'https://search.maven.org/solrsearch/select' for sha1 hash '4858e51d5290a3640f706ed0c7db8eda5c646899'. Detected supported file(s) in '.', but there was a problem generating a dep-graph. No Maven artifacts found when searching https://search.maven.org/solrsearch/select
Mend (a.k.a. Whitesource)? “No dependencies were identified”
Mend also does not seem to be able to scan this:
$ ws scan –extended .
Initializing: File system scan is not allowed, only package manager dependencies resolution is performed Scanning: /opt/automated-benchmark/ssl/not-yet-commons-ssl-0.3.17 [...../] Retrieving: Security vulnerabilities and compliance information [...../] No dependencies were identified
Many important Java systems are still built using Ant, but unfortunately, most application security tools are not able to understand and scan such systems. MergeBase, however, uses a powerful signature-matching algorithm that works wonderfully well with Ant-based Java projects!
As cybercrime becomes more sophisticated, governments have begun introducing initiatives to hold regulated industries accountable for their data security. This includes initiatives involving third-party liability, where software companies are held responsible for vulnerabilities that come from external sources.
This is an important issue for both software providers and regulated companies using third-party software. Here, you’ll get an overview of what third-party liability is, why it matters, and what you can do to prepare for third-party liability laws.
What is third-party liability in software?
Third-party liability refers to a company’s responsibility to keep their data, and their users’ data secure from any vulnerabilities—including vulnerabilities introduced by code from third parties.
Most software companies incorporate libraries from third-party sources in their offerings. If one of these third-party libraries becomes vulnerable to cybersecurity threats at any time, the company is still liable for any breaches of their own data.
Key terms to know when discussing third-party liability
If your company is discussing cybersecurity, odds are good that third-party liability will come up. The following terms are often used in conversations about this matter:
Third-party vulnerabilities: these are the specific vulnerabilities introduced by third-party code.
Software supply chain: this refers to all the elements that go into creating and delivering your software product. This can include hardware, open- and closed-source code, operating systems, consultants, and testing tools. It’s everything that touches your application as it’s being made, and everything that touches those things, and everything that touches those things, and so on.
Software bill of materials (SBOM): this refers to the full list of libraries that make up a software system, including code from vendors and open-source libraries. This terminology is more often used in discussions of cyber security policy and legislation.
The regulatory gap: how third-party liability became so important
Third-party liability became an important issue due to the extreme regulatory gap between software companies and industries that play an established, essential role in societies’ infrastructure.
The world came to rely on (unregulated) tech companies
In the 1990s, industries like finance, transportation, energy, and healthcare had already cemented themselves into the infrastructure of society. These industries were vital to the average citizen’s daily life as well as economies as a whole; therefore, governing bodies heavily regulated them.
This regulation prevented any one regulated company from growing to the point of global scale. (For example, there is no worldwide consumer bank.) This meant that innovations happened on a smaller scale, and regulators were, for the most part, able to keep in step with those innovations.
However, the internet and ubiquitous use of personal computers (and later smartphones and other smart devices) led to increasing global demand for software services. When the tech industry began, software applications were not regulated. Tech companies multiplied and innovated, and the capabilities of software increased exponentially.
In a matter of decades, software applications have become a crucial part of everyday life worldwide. Consumers relied on large tech companies for commerce, navigation, and communication—but so did small and mid-size businesses, enterprise corporations, and even government entities.
Innovation relied on third-party code
As software capabilities expanded, more and more tech companies began building applications on code libraries written by outside sources. This was essential to economic survival. In order to innovate efficiently and competitively, tech companies couldn’t start from scratch. Today, most commercial software applications are built on a mix of proprietary in-house code and third-party libraries—much of which are open-source.
These third-party providers were also unregulated. An ecommerce marketplace in Spain could license a transaction processing system from a US fintech startup, which might include code libraries produced by companies in Mexico, Norway, Singapore, and Germany—or even open-source code with no single identifiable author. (And each contributing company could have built their code on even more third-party libraries.)
Since none of these companies were regulated, any cyber security standards were either set by the buyers or self-imposed.
This became especially problematic when highly regulated corporations and government entities began using unregulated applications.
Third-party code became an easy target for cybercriminals
A system is only as secure as its weakest component. Breaching an enterprise application is difficult, and malevolent hackers soon realized that it was much easier to breach a large entity’s data by simply targeting code produced by smaller players. Hacking a third-party software supplier created a “back door” to the supplier’s customers, clients, and partners.
This was a known issue in the software community for a long time, but in 2021, it became a matter of national security in the United States.
In 2020, presumed Russian hackers gained access to an IT monitoring system created by SolarWinds. SolarWinds was a third-party supplier to large companies, including Microsoft, Cisco, and Intel, as well as US federal departments, including Homeland Security, State, and Treasury. Through SolarWinds, the hackers gained access to more than 18,000 organizations’ data—and the breach wasn’t discovered until the spring of 2021.
This was not an isolated incident. Third-party software supply chain attacks have been increasing exponentially in the past few years—and it’s leading governments to make laws regarding third-party liability.
Third-party liability in cyber security law
Because of the growing threat of third-party attacks, governments have begun forming policies to hold companies accountable for the security of their applications—including the security of their third-party suppliers.
Third-party liability policy can be thought of as a spectrum across two general approaches, the prescriptive approach and the principled approach.
The prescriptive approach: focus on the rules
Governments taking a prescriptive approach to software supply chain security (like the United States) set compliance standards for key industries. Regulated companies and government entities are required to hold all vendors to a known set of security standards. Procedures are likewise set in place for when these standards are breached.
The advantage of this approach is that both regulated customers and their vendors know if they are compliant and what to do if suddenly they’re not (i.e., they’ve been hacked). This makes it easier for vendors to become compliant and easier for customers to determine which vendors are eligible for consideration.
However, this approach has a major disadvantage: reality moves faster than regulations. The measures a government prescribes can become obsolete, and changing regulatory standards takes time. This lag effect can burden industries with (expensive) outdated compliance standards that don’t actually protect them from threats.
The principled approach: focus on the results
Governments taking a principled approach (like Germany) instead leave compliance standards up to the software companies—but penalize them heavily for any breaches. Regulated companies and government agencies are held to the standard of perfection: if you’re hacked, it’s because you weren’t secure enough.
The disadvantage with this approach is that there is no clear-cut compliance standard (aside from being unbreachable). This makes it more difficult for regulated customers to source innovative vendors. Likewise, vendors lack clear security standards to meet in order to know if they are eligible, let alone a competitive solution.
On the other hand, this approach has the advantage of incentivising both third-party vendors and regulated entities to innovate at the speed of malevolent hackers. By raising the stakes of failure, principled policies encourage regulated entities to make absolutely sure that their suppliers and their suppliers’ suppliers are secure.
How to prepare for third-party liability laws
As governments begin exploring cyber security policies, software vendors and regulated clients need to invest in tools and practices that will keep them compliant. And even if you’re not operating in a regulated space, protecting yourself (and your users, customers, and partners) from third-party vulnerabilities is a smart idea.
How to prepare as a vendor
If you create software, you need to ensure that both your own code and your third-party code are vulnerability-free. You can do this with a software composition analysis (SCA) solution like MergeBase. An SCA solution analyzes every library that touches your final product and alerts you of any vulnerabilities.
In addition, you should begin the practice of preparing your software bill of materials for every contract. Future contracts in regulated spaces will depend on your ability to provide up-to-date information about where your code comes from, so it’s wise to begin preparing for this now.
How to prepare as a regulated client
If you are in a regulated industry, third-party liability laws will put the onus on you to ensure that your vendors are using proper data security. In order to protect yourself and your stakeholders, you will need to do two things:
Obtain a software bill of materials from every vendor. You need to know exactly what code is being used for each contract. This is not always easy to do. Your vendors may not have a one-size-fits-all SBOM for every contract—and they may not have internally prepared their SBOMs for external viewing.
Analyze every vendor’s SBOM. In addition to obtaining the vendors’ SBOMs, you need to analyze them for vulnerabilities yourself. (This is especially key if you are operating under laws that take the principled approach discussed earlier.)
Both of these can be very difficult to do because they involve inspecting another organization’s code. This is why using an advanced SCA suite like MergeBase is a good idea. MergeBase allows you to analyze anyone’s SBOM for vulnerabilities, even if you do not have direct access to their code. (You can even use MergeBase to verify the SBOMs your vendors give you—we have a reputation for generating SBOMs that are even more thorough and accurate than those a vendor creates in-house.)
It’s a reliable way to know exactly how secure a vendor is.
Don’t let third-party liability catch you off guard
Third-party liability laws are coming, and whether you’re a software producer or customer, the best thing to do now is prepared. MergeBase gives you the ability to find vulnerabilities in your own code as well as code from suppliers and vendors—which helps protect you from third-party liabilities.
If you want to prepare for third-party liability laws, we would love to show you how MergeBase can help. Book a demo with us today and see how you can protect yourself, your code, and your customers.
The unofficial, unauthorized retrospective, 9 months later.
If it was not clear before, after Log4j, it certainly is now! Everybody uses open-source software in their applications. There are no exceptions, and as a result, we are all at risk of being breached by vulnerabilities in open-source software. The Log4J bug was a wake-up call.
The Apache Log4j vulnerability was one of the most significant breaches in recent history. Its impact was felt worldwide, and the repercussions are still being felt today.
In this live event, Lunasec founder and CEO Free Wortley, AppSec Expert Jim Manico, and vulnerability scanning implementor (and Apache committer) Julius Musseau come together to discuss the 2021 Log4J debacle.
It’s been nine months since the Log4j vulnerability was disclosed! Aside from Minecraft, have any serious breaches dropped in the last 9 months? Or did everyone fix it in time? And what was so special about this bug?
To understand the issue and prepare for the future, we need to analyze the root causes of the breach and come up with a set of recommendations that can help prevent similar issues.
What did library developers learn from the incident?
What have common app developers learned?
How should the software industry prepare for future incidents of this scale?
Learn from the past and prepare for the future.
Live Event Highlight
1999 – Log4J 1. x is born
2014 – Log4J 2.x is born (includes: JNDILookup.class)
2015 – General purpose JNDI exploit technique demonstrated at BlackHat
2021 – November 24th – Vulnerability shared (privately) with Apache
2021 – December 4th – An interesting commit lands
2021 – December 9th – First Annual Log4J Global Day of Celebration
The CSRB’s report addresses the continued risk posed by vulnerabilities discovered in late 2021 in the widely used Log4j open-source software library, one of the most serious vulnerabilities discovered in recent years.
It contains 19 recommendations for government and industry, focusing on driving better security in software products and enhancing public and private sector organizations’ ability to respond to severe vulnerabilities. The goal is to identify and share lessons learned to enable advances in national cybersecurity.
Advice for library Developers
Be more careful when preparing the fix.
Github has the capability to make the pull requests and the issues private even though you’re running on a public repo.
Security audit code audit needs to be happening regularly with libraries that are used everywhere.
Advice for library consumers (a.k.a. Software engineers)
Know the libraries that you have (SBOM)
Keep your libraries updated and patched.
Keep tabs on your SCA tool – for example: How quickly was your team able to become aware of the path and how quickly they are able to apply the patch?
Advice for CISO’S & Executives
Don’t let your developers pick any third-party library enrolled in production; you need a stronger vetting process and understand the business risk of choosing a third party.
Running an SCA tool, like MergeBase, several times a day.
Have the willingness to update your libraries. Suggestion: keep all your libraries updated but keep one month behind an update unless you need to be at the bleeding edge because there’s a security vulnerability. Otherwise, keep a month behind the top level and then update it to avoid supply chain issues.
I needed some SBOM samples to test an upcoming MergeBase feature (we plan to offer SBOM import in addition to our existing SBOM export feature). So I grabbed 5 tools for generating SBOM, more or less randomly, and tried them out. Here’s what I found!
I whipped up a small Java Maven project (see: log4j-transitive-example.git) that transitively depended on Log4J. That way I could assess tools both for how well they generated SBOM when source code was available and when it wasn’t. I also put together a small Docker image in which I manually added a single vulnerable “jsch-1.3.8.jar” library under /opt/jsch/, since a lot of these tools offer SBOM generation from Docker images, and I wanted to exercise this particular use case (software added using Docker’s “COPY” command instead of via package-management).
With these samples ready, I essentially ran 3 tests against each SBOM generation tool:
Generate SBOM from source code (the Log4J transitive project, pre-build).
Generate SBOM from a deployed system (again, the Log4J transitive project, but post-build).
1. Can it generate SBOM from something I acquired (no source code)? No.
2. Can it generate SBOM from something I built (full source code)? Yes.
3. Can it generate SBOM from a Docker image? No.
4. Are transitive dependencies included in the SBOM? Yes, beautifully. Multi-module and maven-profiles are handled beautifully as well.
5. Ease Of Deployment Difficult to start, but wonderful after that point! Imagine a car where it’s *very* difficult to open the door the first time, but once you’re in the driver’s seat, it drives beautifully and intuitively. You need to know how to edit your project’s Maven pom.xml to activate the CycloneDX generation for your project. The documentation was not great for a newcomer (it assumed Maven expertise). But once you got it working, the default behaviour generated excellent SBOM files.
6. Comments CycloneDX founder (Steve Springett) is clearly deeply (and by that, I mean *deeply profoundly*) proficient with Maven and Java. The resulting SBOM is ideal (as good as is possible). Anyone building a Java/Maven project should immediately enable this and start including it in their builds! Looking at the git commit history for this project – yup, Mr. Springett is definitely to blame for a work of beauty here (commit-counts by author)!
1 Author: aalzate
1 Author: Gregory Anne
1 Author: iabudiab
1 Author: Jonas Arnold Clasen
1 Author: Mirko Friedenhagen
1 Author: Robert Klaus
1 Author: Robert Varga
3 Author: Hervé Boutemy
4 Author: Prabhu Subramanian
5 Author: Thomas Gaskell
5 Author: M. Scott Ford
55 Author: dependabot
324 Author: Steve Springett
The problem, though, is that it requires a reasonable understanding of Maven to enable.
Note: Based on our own Maven and software-composition expertise, here at MergeBase we recommend the following configuration when using cyclonedx-maven-plugin:
1. Can it generate SBOM from something I acquired (no source code)? Yes.
2. Can it generate SBOM from something I built (full source code)? Yes, but not as good (e.g., for log4j-transitive sample, it only listed the single top-level dep (“twilio-8.6.1.jar”).
3. Can it generate SBOM from a Docker image? Yes, but in its “Docker” mode it seems to only query the package-manager. It did not notice that I had copied in /opt/jsch/jsch-0.1.38.jar (no mention of “jsch” in the resulting SBOM).
4. Transitive Dependencies Yes, but ONLY in the post-build directory scan mode, and as a flat list, not as interconnected relationships (this makes sense since they are all lying together on the disk together).
5. Ease of Deployment Very easy. But somewhat single-minded in its approach. By this, I mean this tool is very easy to operate, and it will do exactly what you tell it to do, but not necessarily what you wanted! In a way, I appreciate Syft’s “just scan everything” philosophy. E.g., “syft -o json /” – it’s gonna go for it (scan my complete file-system from root).
This contrasts with cyclonedx-maven-plugin’s approach, which is more: “if you configure me incorrectly, I will do nothing, but if you do manage to get me actually working, from then on I will provide perfect output, more perfect than you ever even knew or dreamed or thought possible.”
6. Comments I suspect Syft is looking at whatever it can find inside the files on disk (e.g., inside “commons-io.jar” it must be quickly considering ./META-INF/maven/commons-io/commons-io/pom.properties). I didn’t look at Syft’s internal logic, but the reason I think it’s working this way is because jsch-0.1.38.jar does not have a pom.properties inside, and so Syft messed it up ("bom-ref": "pkg:firstname.lastname@example.org"). Assuming that’s a heuristic, that’s a damn fine heuristic, though! It would actually work for jsch-0.1.29 and older!
Nonetheless, Syft is a pretty amazing tool, especially considering it’s free/open-source.
One minor criticism – what’s with all these spurious “cpe23” entries in the JSON?
1. Can it generate SBOM from something I acquired (no source code)? It depends on your definition of “SBOM.” Yes, this tool is willing to run “ls” or “dir” recursively and re-assemble the output into a file that is technically a valid SBOM file. But I need a “packages” section in my SBOM, and it didn’t create one. The “files” section it did create and fill with data is mostly useless for the problems SBOM is supposed to help solve.
2. Can it generate SBOM from something I built (full source code)? Yes. This tool automatically realised that it needed to run “mvn dependency:tree” and it knew how to reformat that into a useful SBOM file, including a “packages” section
3. Can it generate SBOM from a Docker image? Yes? No? I’m not sure. It says it can, and when I asked it to do this, it obviously did something and even correctly printed the number of Alpine packages in my Docker image. But there was no resulting SBOM file.
4. Transitive Dependencies Ha! Very funny! No, they are not included in the output, although SPDX’s “dependency” feature *IS* used to list all the Maven references (but flattened). Like so:
5. Ease of Deployment Medium difficulty. The tool requires a lot of command-line arguments, but the error messages and help-text guided me reasonably well.
6. Comments I was disappointed by this tool, mainly for three reasons:
– Not including a “packages” section (when source code is not available) really defeats the point of SBOM. So I do worry that people might be happily using this tool and thinking they are getting good SBOM files out of it, when they really are essentially getting garbage.
– Also, when the source code is available, I was a little disappointed that the full dependency-tree was flattened instead of keeping its original structure. But this was a relatively small disappointment – at least all the 3rd party libraries were accurately recorded!
– Finally, I was not able to generate SBOM for a Docker image, even though it seemed to happily process the image I provided.
Unfortunately, the generated SBOM file was not particularly useful. This is not really a useful way to identify this library (uhh, natural language?) !!!
PackageName: Apache Log4j API
I would much prefer something that could be be mapped back to Maven-Central coordinates (e.g., repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.14.0/ or, if you prefer, groupId=org.apache.logging and artifactId=log4j-api) since both of these are unambiguous and both are essentially how developers think and talk about these dependencies in the first place! Another great option: use PURLs!
Finally, the license info included in the SBOM output made no sense to me:
I quickly ran my own manual analysis of “Log4J-API-2.14.0” to verify these claimed licenses (note: I’m not a lawyer, but I have published academic papers on this problem, and I’m also an Apache committer). I could find ZERO pieces of evidence suggesting that MIT or Apache-1.1 were remotely appropriate here. Flagging “Apache-1.1” as a possible license here, while not only inaccurate, could also cause bigger problems since Apache-1.1 is famously incompatible when combined with GPL software (whereas MIT is a benign and highly cross-compatible license).
1. Can it generate SBOM from something I acquired (no source code)? Yes. MergeBase is able to analyse binary applications, including Java and .NET and subsequently generate an SBOM with the click of button, or in an automated workflow.
2. Can it generate SBOM from something I built (full source code)? Yes. Same as 1
3. Can it generate SBOM from a Docker image? Yes.
4. Are transitive dependencies included in the SBOM? Yes.
5. Ease Of Deployment Excellent.
Not only is MergeBase the most comprehensive SCA tool to create SBOM’s with, it also is able to import SBOM’s and automatically do a full risk analysis on it for security, legal and technical (debt) risks.
1. Can it generate SBOM from something I acquired (no source code)? See answer #2.
2. Can it generate SBOM from something I built (full source code)? I guess technically the result is a valid SBOM file….
3. Can it generate SBOM from a Docker image? Again, see answer #2 (above).
4. Are transitive dependencies included in the SBOM? Yes, except Snyk’s SBOM implementation here has a game-over flaw (see answer #2, and see comments below).
5. Ease Of Deployment Excellent: npm install -g snyk2spdx.
6. Comments One has to wonder what they were thinking! Yes the end-result is a valid SBOM file, but it lacks a “packages” section. It even lacks the useless “files” section.
What does it have instead? A “vulnerabilities” section !!!
To bring this back to SBOM’s original shipping metaphor (a “bill of materials”), this would be like asking IKEA to send you the list of parts for a particular bunkbed. And IKEA answering with: “We looked up all the parts for the bunkbed. Please find enclosed a description of 3 of those parts (out of an unknown total). These particular 3 parts contributed to serious bunkbed failures in the last 5 years. We’ve included descriptions of how they failed for your convenience. Enjoy your SBOM!”
If we are not understanding this tool, or if Snyk has a different, more appropriate SBOM offering, I would love an email from Snyk to help me understand this better (you can reach me at email@example.com).
Gareth Rushgrove (VP, Product Management) sent me an email. In his own words:
The snyk2spdx tool is not meant to generate an SBOM. It was an experiment looking at the WIP vulnerability extension in the draft SPDX 3.0 spec. We built the snyk2spdx tool to kick the tires there. Technically it’s generating a basic VEX.
This is very helpful information – thank you Snyk! This is a good point: I mistakenly assumed that “snyk2spdx” was an SBOM generator (since SBOM is SPDX’s primary use case these days), but SPDX can be used for other purposes.
Gareth also mentioned that Snyk is working on bringing SBOM generation to their main “snyk” command-line tool, and that they are also piloting an ability right now to work with CycloneDX data directly from Git repositories. Working directly from Git repositories (without invoking build tools) is a whole other kettle of fish that I did not touch on here! Very exciting!
If you can, use CycloneDX native plugins for your software systems. These produce perfect SBOMs for your software that you can confidently share with your customers. But you must remember to enable CycloneDX for each language in your software (which can require a bit of work).
However, if you do not have access to source code, we recommend Syft (free) or MergeBase (free trial), since both of these products are able to produce accurate, useful SBOMs when source code is not available.
When generating SBOMs from Docker images, it’s very important to understand that many SBOM generators tend to only query the package-management system, and so Docker-derived SBOMs will probably usually miss the most important part of the image – the actual software you are trying to run inside Docker!
Doesn’t have access to source code and want to generate an SBOM?
APIs are everywhere, and their security is becoming challenging.
It goes without saying that APIs are deployed everywhere. For instance a website click quickly initiates a dozen REST calls directly from your browser and another dozen behind the scenes. Software engineers, like you, integrate with APIs more and more to develop new features and enhancements.
Gartner is seeing explosive growth of APIs, and estimates that by 2025 less than 50% of enterprise APIs will be managed; the companies just don’t have the capacity to do it.
Are you able to secure your company’s API sprawl?
As software engineers, we can divide APIs into two kinds: those we build & maintain ourselves (the homegrown); and those we consume (the 3rd-party externals). In this webinar, TeejLab Founder & CEO Dr. Baljeet Malhotra and MergeBase CTO Julius Musseau talked about API risks, API governance, and best practices for software engineers building and consuming APIs.
They covered the following topics:
Why it’s essential to think about risk when building APIs
How to protect your company from the potential damage caused by a compromised API
Why is this important? The same report points out that web application attacks are the second most frequent attack pattern after DoS. So, if your organization has not been hit in this area, chances are you will be. Get ready!
The good, the bad and the ugly
Be warned; there are no quick fixes! No magical tools resolve this for you. Developers’ first response is mostly to ignore access control as an issue and to make matters worse. Application frameworks rarely provide details about their functionality since it’s not particularly generalizable.
But don’t despair! Approaches to resolve this are mature and well-developed. Watch this webinar with Application Security experts Jim Manico (OWASP Top Ten contributor), Erwin Geirnaert (Co-founder & Chief Hacking Officer at Shift Left Security) and Julius Musseau (CTO at Mergebase) to learn about guidelines, patterns, as well as pitfalls to avoid it.
What will you learn in this course?
– First, What defines the terms “access control” and “authorization,” and why are these still hard to get right?
– The building blocks developers need to know about it:
Learn how to apply the principle of least privilege when building access control in your applications.
Learn how to use the suitable data types for access control decisions
Learn how to build data-centric access control system to avoid Indirect Object Reference (IOR) issues.
We are going to look at some of the building blocks around good access control. Talk about principal lease privilege we want to look at, like what data we should be using at the point of making an ac decision.
– Best protection strategies to prevent it and then one of the more difficult things, indirect object reference. It is data-specific access control, and we’re going to come up with some protection strategies and design principles.
So, if you want to learn more about what makes applications so vulnerable and what you can do about it, this is the webinar you won’t want to miss!
What is Access Control and Authorization?
AC is about selectively restricting access in a piece of software right various features and various resource access. Authorization is when you give permission to a particular user or entity to access certain features or data again. In other words, access control is the act of restricting access, and authorization is the act of giving someone access to a specific part of your software.
How do most people do access control?
They use Role Based Access Control (RBAC), which is the most common access control implemented in most web frameworks. Usually, you check in a hard-coded way what role the user is correct. This is a policy enforcement point somewhere in the software where you can check if the user has permission to execute this feature.
However, hard coding has some problems:
It makes “proving” the policy of an application difficult for audit or Q/A purposes.
Any time the access control policy changes to be updated, new code needs to be pushed.
It does not support horizontal ac.
It is often not “automatic” and needs to be “hand-coded” for each application feature.
It does not support multi-tenancy.
Why is it still difficult? What is the challenge?
It is difficult for developers to build. Frameworks rarely provide detailed ac functionality.
It is difficult to test from automated tools. Scanning tools are rarely aware of your custom access control policies.
Access Control Sequence: If you have a big sequence and it is hard to look down everything, protect the steps that will hurt your business
The latest OWASP Top 10 ranks “Cryptographic Failures” as the 2nd worst security problem currently facing software engineers today. In this webinar AppSec experts Jim Manico (OWASP Top Ten contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will discuss why this is the case, and offer the best practices and resources for developers trying to avoid such failures in their own systems.
As the very recent (and very serious) CVE-2022-21449 shows – this problem never goes away! It’s hard for software practitioners to stay up-to-date, because new critical cryptographic weaknesses and configuration disasters are discovered and disseminated every year, and seemingly tiny benign mistakes can be game over.
Answers to the following questions are critical in avoiding cyber failure:
Should you use Argon2 or bcrypt?
When should you salt things?
What parameters should you feed into your TLS endpoints?
Anything to be careful about with JWT?
Watch the video of our webinar on How To Avoid Cryptographic Failures from June 3rd, 2022
In this webinar, application security heavyweights Jim Manico (OWASP Top Ten contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will talk about the best thing that can happen to you if your application security team is overwhelmed, overworked and over-worried.
ASVS is a set of best practices that can be used by any organization, large or small, to assess the security of their applications. It takes a proactive, risk-based approach to secure applications and is designed to be flexible enough for you to customize it for your specific needs.
Are you thinking of establishing a balanced appsec process, or are you looking at fine-tuning your existing process?
What you will learn in this section:
The first application security standard by developers for developers!
That defines three risk levels with 200+ controls.
And gives you a similar value to ISO 27034 for a fraction of the hassle
Did you like this webinar? Don’t miss the next ones! Secure your spot today!