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.
Zero Trust (ZT) has been the source of hope and confusion for many organizations looking to improve and modernize their security program.
It is not a new concept, but President Biden’s 2021 Executive Order has recently highlighted it. The order cites Zero Trust, Software Supply Chains, and SBOM as critical pieces toward better securing American institutions and people against cyber attacks.
There is wide agreement that ZT concepts lead in a positive direction toward better security. Implementing it requires fundamental changes and raises questions: How does it really work? How do I apply it? What are its implications?
In this webinar, Jerry Hoff and Julius Musseau break down Zero Trust’s fundamental concepts and resources. Also, they looked at Zero Trust’s implications for Applications, SBOM and Software Supply Chains.
Watch it now:
Zero trust is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.
ZT provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privileged per-request access decisions in information systems and services in the face of a network viewed as compromised.
Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a ZT enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.
Strong Identity, Authorization & Data
Which effectively means
Strong Authentication / Identity is paramount
Identity based access control for all connections
Encryption on all connections
Consistent application of security rules
Cloud and on prem workloads
Remote and on prem workers
Device Control / Inspection
Deliberate access granting / strong governance
Base Pillars to build ZT
High-Level ZT Maturity Model
Need for unified, centralized, overarching authentication
Need for centralized authorization & decision-making capabilities
Need for device information
Updated SOC capabilities (EDR)
Updated Training for Staff (design, implementation, deployment, production)
With the growing interest in software bill of materials (SBOM) management from world governments, you might be wondering, “Where is this all leading?”
Based on trends in politics, the history of cybersecurity, and our own industry experience, we’ve put together a list of things that you can expect to happen in the near future of SBOM and software supply chain security management. We’ll unpack them all in detail, but in brief:
Read along to see why we’re expecting this for the future of software security.
Prediction 1: Highly regulated industries will be the SBOM early adopters
Regulators and policymakers are keen to keep vital parts of commercial and societal infrastructure secure. As cybersecurity law continues to address software supply chain security, we expect that early mandates will target organizations in industries that are already subject to high security regulations. Some of these industries, like finance and telecommunications, are already preparing for SBOM practices in the wake of the political activity mentioned earlier.
Because government entities, banks, and telecom companies will require SBOMs from their vendors, we naturally expect these vendors to be the first to adopt SBOM generation practices as the norm. Adopting these will be essential to continuing longstanding business partnerships, so vendors will find ways to implement these practices for their highly regulated customers.
This is in keeping with how industries have adopted other cybersecurity standards. In 2021, the Institute of Electrical and Electronics Engineers conducted a study regarding the adoption of ISO/IEC 27001 security standards by companies in Germany. Sectors such as information and communication, finance, and public utility had much higher observed adoption rates than sectors like construction and retail—and consulting services companies had a disproportionately high adoption rate as well.
Adopting software supply chain security practices won’t necessarily be easy for these vendors or their customers, so we expect to see some of the following subtrends emerge soon:
Increased literature from governments regarding requirements, use cases, and implementation of software supply chain security. For example, the U.S. National Telecommunications and Information Administration has already published a small library of documents to help organizations understand and implement SBOM practices themselves. However, most of this material was published in the years 2019–2021. In the near future (as SBOM laws and mandates come into full effect), we expect to see more documentation and a library that stays up-to-date.
A rise in demand for in-house software supply chain security expertise. SBOM domain knowledge will become a sought-after skill when recruiting IT and security leadership—and more companies in these industries will staff positions dedicated to SBOM practices.
Because vendors will want to become SBOM-compliant quickly, we can also expect to see more SBOM consultants. Individuals with in-house SBOM implementation and change management experience will realize that the supply-demand environment is in their favor, and begin consulting multiple clients as independent contractors. Large consulting firms will take advantage of the hype and begin offering these implementation services themselves as a way to expand existing accounts and initiate new client relationships.
Prediction 2: SBOM infrastructure norms will be specific to early-adopting industries
Because these industries have the most incentive to adopt SBOM practices, they will be the ones who shape the early infrastructure around these practices. This will be a collaborative, decentralized process involving the regulated organizations, their vendors, and the regulators themselves.
For the industries themselves, this will be a process of adopting tools and operations that keep them in the compliant zone. These agents are categorically slow-moving, and so they will gravitate toward solutions that check compliance boxes in the least invasive way possible.
For vendors who only serve a few customers in these industries, SBOM practices will be customer-led and customer-specific: XYZ Bank will make their SBOM requirements known to vendors, and the vendors will meet them on an account-by-account basis. Vendors whose business relies on this customer base, on the other hand, will take note of what these customers are asking for, and develop in-house SBOM policies that satisfy all or most vendors’ needs—this will be necessary to build and maintain confidence, streamline the customer onboarding process, and expedite sales cycles.
For regulators, this will be a process of tightening, tweaking, and troubleshooting the rulebook. Regulators who prefer a top-down approach will impose rules, see what happens, and adjust them for future success. Those who prefer a more collaborative approach will work with the industries (and possibly notable vendors) to find ways to maintain a high level of security without impeding business operations.
The outflow of this process will be a mix of official and unofficial best practices for SBOM compliance, including implementation frameworks, standard operating procedures, and of course, preferred formats and tools.
This is how we expect the SBOM infrastructure to develop within the industries that are already under pressure to up their software supply chain security—but what about the critical infrastructure industries that aren’t highly regulated in this regard?
Prediction 3: Other critical infrastructure industries will only adopt SBOM practices when required to
Security is absolutely vital to financial and telecom companies’ abilities to do business, and foundational for stable and trustworthy government operations. It would be disturbing to find out that your company’s 401k provider (or your country’s department of defense) had been hacked, but you might not be so worried if you heard the same about your electricity provider.
Not every critical infrastructure industry sees an airtight SBOM as a critical business priority, and so we expect that industries like healthcare, agriculture, and energy will not adopt SBOM practices until they have to.
We’ve seen this play out before. In 2014, the National Institute of Standards and Technology (NIST) issued their Framework for Improving Critical Infrastructure Cybersecurity—pursuant to a 2013 executive order to improve critical infrastructure cybersecurity. But as of February 2022, the Government Accountability Office found that only three of the sixteen critical infrastructure sectors in the country had adopted the framework. (Two other industries had taken some first steps, and the rest hadn’t made any measurable progress at all.)
So what will push these industries to start using SBOMs? Enter our next prediction.
Prediction 4: Crime and legislation will be the primary drivers of SBOM adoption
Since it’s unlikely that industry sectors will adopt SBOM practices voluntarily, we see two main catalysts driving adoption in the future: crime and legislation.
Hackers will continue to find new ways to exploit transitive vulnerabilities. Malware agents will continue to test the limits of how much companies will pay to make a problem go away. And as other sectors secure their supply chains, digital ne’er-do-wells will find less-secure sectors to be more lucrative targets.
As this happens, the unlucky victims of these attacks will seek out ways to keep them from happening again. (And some companies will adopt stricter software supply chain security practices so that the same thing doesn’t happen to them.)
Especially catastrophic breaches (think SolarWinds) will prompt government action, and cybersecurity policymakers will propose more acts to mitigate these threats—sometimes at the industry level, sometimes in a broader sense. This will raise the minimum security requirements in these slow-to-adopt sectors as well.
Some legislation may grant positive incentives for companies who meet certain levels of non-mandatory compliance. Other laws might impose fines, penalties, and possibly more severe punishments on organizations that don’t stay compliant on this front.
In the future, industries will find themselves squeezed into SBOM adoption by hackers on one side and the government on the other.
Prediction 5: SaaS and open source communities will leapfrog the early adopters
When industries are ready to take SBOM seriously, who will be there to help them adopt? Enterprise cloud-based SaaS!
Because the early years of SBOM adoption will be focused on highly regulated industries, most of the standard operating procedures will be specific to those sectors. When new sectors begin looking for ways to protect their software supply chain, they’ll need solutions that can be easily implemented in their own industries.
SaaS vendors will be the most likely to fill the gap. They’ll notice the growing demand and meet it with cloud-based security services. Enterprise cloud-based SaaS companies have already had to overcome rigorous security screenings in order to offer their other services—so they will be the prime candidates for offering compliant and secure software supply chain security solutions to industries new to the discipline.
We expect the tech giants to develop and offer SBOM solutions to enterprise clients in the future. We also expect nimble startups to emerge, perfecting smaller functions of supply chain security (and likely being acquired by larger players).
In addition, open source communities may become a source of SBOM solutions as well. While it would be difficult to impose supply chain security regulations on open source authors, it’s possible that leaders in the community will come to see security as an altruistic cause. (What’s better than giving someone a free meal? Giving them a free meal with a transparent list of ingredients!)
If both of these predictions are true, we will have a scenario in which enterprise SaaS makes SBOM management easier on the vendor-customer side, while open source communities make it easier on the product development site. At this point, SBOM management infrastructure will break out of the highly regulated enclave and become more accessible to all industries.
Prediction 6: SBOM fraud will have its day (and stricter regulation will follow)
There will always be someone who tries to game the system. If SBOM management becomes the expected norm, eventually there will be those who wonder, “What corners can I get away with cutting?”
Ideally, SBOMs will be publicly available and easy to check from the outside. However, if customers and auditors become lax in doing their due diligence (or just overwhelmed by the sheer number of SBOMs they’re responsible for checking), then fraudulent SBOMs will be able to slip through the cracks.
Eventually, this will become a concerning enough issue to excite the original SBOM adoption catalysts: crime and legislation. Fraudulent SBOMs will leave customers vulnerable to hackers, which will lead to more breaches, which will lead to stricter regulations and auditing practices.
How to prepare for the future of SBOM
These are our predictions for the future of software supply chain security management based on both history and our experience in the industry. If you’re an enterprise software customer, we recommend getting ahead of the game: start talking to your vendors about their SBOMs, and consider using a software composition analysis tool that allows you to check your vendors SBOMs yourself (like MergeBase).
If you’d like to explore how MergeBase can help you prepare for the future of software supply chain security, book a demo with us—we’ll show you how it works!
Are you relying on your container scanning to secure your applications? You might be exposed!
Containers have taken IT by storm. They increase delivery speed and stability. To secure them, you just run a scanner, right? Perhaps…
Metal detectors cannot detect plastic explosives. Similarly, many container scanners (e.g., Quay, Docker Hub, and even Snyk) are unable to detect the most vulnerable libraries inside Docker containers or Kubernetes clusters.
Do you want to know what your container scanner might be missing?
Watch this live streaming event with the heavyweight security expert Julius Musseau, where he highlights the issues and presents solutions. Learn about the typical container scanning short falls.
What you learn (takeaways)
Where most container scanners fall short (and can seriously hurt you).
A methodology to evaluate container scanners
How to simplify application security AND improve container scanning (too good to be true?)
I created 3 “log4j” container images. (If you want to play with these container images, click here)
1.) Easy Mode – container created using “apt install liblog4j”. This brings in log4j via Ubuntu’s own native package manager.
2.) Medium Mode – the container was created by downloading log4j from Maven directly to disk. (This mode best simulates what developers normally do.) I even rezipped the jar to cause all the timestamps to refresh (which alters the sha1, of course), but this did not trick any scanners.
3.) Hard Mode – same as #2 except the following 3 files are removed from “log4j-core-2.14.1.jar” before scanning it:
I didn’t expect this at all, but all the container scanners (except MergeBase) are barfing a ton of uninteresting CVEs against the “ubuntu:20.04” latest base image. This is an LTS image under active support (still receives security patches) until 2023. Why are the scanners reporting a bunch of vulns against it (including some from 2016)? This doesn’t make any sense!
As an end-user, there’s nothing I can do!
apt update apt dist-upgrade
Ubuntu reports, “You’re completely up to date; there’s nothing to do!” but the scanners are still reporting vulnerabilities. Why not warn me that the sun will explode in 5 billion years while you’re at it?
Container Scanning – The Actual Results
It turns out most container scanners are police officers where if you say, “oh, sorry, officer, I seem to have misplaced my driver’s license,” they just let you go!
This could be a problem because:
1. Some libraries don’t include metadata files – either on purpose, or by accident, or by historical happenstance (e.g., the metadata format had not been standardized back in 2005 when the Jar was created). 2. Open source logic can be mixed and imported in different ways (open source licenses usually don’t forbid this), and metadata might get altered or omitted during such transformations. Copy/paste, anyone? 3. Finally, what if someone maliciously removes or alters the metadata?
When evaluating scanners, it’s very important to examine them with a pre-seeded known-vulnerable sample (preferably one you create yourself) during your tool selection process (and perhaps during an annual check-up/review).
And one final caveat: I suspect the scanners were all carefully tuned to detect log4j (e.g., special one-off logic). I would be pleasantly surprised if they did as well against less infamous (but similarly vulnerable) samples.
MergeBase actually looks at the class files. And so MergeBase detects the vulnerable version in “Hard Mode” regardless of the metadata present or not present.
Ready to try our SCA tool and avoid problems when scanning your container?
OpenSSL has classified an upcoming issue as critical severity as it affects common configurations and can be exploited. So far (it’s October 31st right now as I type this blog post), they are not saying anything else.
OpenSSL is mostly a Linux package, so here is what you should do tomorrow:
Ubuntu/Debian users should run “apt update” and “apt upgrade,”
Redhat/Amazon/Fedora/Suse users should run “yum update,”
Alpine users should run “apk update” and “apk upgrade.”
Any Docker containers running on base images based on any of the above obviously need to be re-imaged!
Typically OpenSSL updates do not require machine restarts, but personally, I would still reboot.
Also, after upgrading, everyone should then type “openssl version” on their machines to verify whether they even have OpenSSL installed and are running a vulnerable version.
For example, on my machine right now (Ubuntu 22.04 – October 31st – 1 day before the security release):
$ openssl version OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
Yikes! I’m vulnerable!
But seeing as it’s still Monday, October 31st, there is not much I can else I can do at this point.
Note: Only OpenSSL versions 3.x before 3.0.7 are vulnerable. They have never released any 2.x versions, and versions that start with 1.x are not vulnerable to this bug.
(For now, let’s pray it’s a runtime weakness in OpenSSL, and not a weakness in private keys generated by OpenSSL since a weakness in generated keys would be a huge headache to deal with – I don’t think keys even retain which version of OpenSSL they were generated by!)
In June of 2022, the Canadian House of Commons introduced their first reading of Bill C-26, an initiative addressing cyber security within Canada’s infrastructure. This bill is not a very controversial document, and if it passes, it will bring about a few significant changes to cyber security standards in Canada.
We don’t know when (or if) C-26 will become law. But because it is keeping with trends in third-party liability law, it’s wise for software companies (and companies involved in Canadian infrastructure) to take note of the bill’s implications.
Bill C-26 deals with an emerging issue in cyber security law—third-party liability. For an overview of this issue and why it’s important, read our Executive’s Guide to Third-party Liability in Cyber Security Law.
A quick overview of Bill C-26
This bill aims to make Canadian infrastructure more secure in two major ways.
First, C-26 would keep Huawei technologies outside of Canadian telecommunications systems by amending the Telecommunications Act. While other nations have built Huawei technology into their 5G networks, Canadian legislators want to protect their network (and their data) from being accessible to the Chinese tech giant.
Second, C-26 would raise cyber security standards for companies that operate vital systems by enacting the Critical Cyber Systems Protection Act (CCSPA).
The CCSPA designates some operators as critical cyber systems (CCSs). The act defines a CCS as a system that “if its confidentiality, integrity, or availability were compromised, could affect the continuity or security of a vital service or vital system.” If the CCSPA is enacted, organizations responsible for critical cyber systems would be required to do the following:
Establish a cybersecurity program within 90 days of becoming a designated operator
Mitigate against third-party and supply-chain risks
Immediately report cybersecurity incidents related to any CCS
Comply with any direction from the Governor in Council with regard to securing CCSs
Adhere to new rules regarding disclosure and use of information
This act applies to designated operators: individuals, partnerships, and unincorporated organizations that belong to at least one of the following classes:
Interprovincial or international pipeline and power line systems
Nuclear energy systems
Transportation systems that are within the legislative authority of Parliament
Clearing and settlement systems
Many companies that would become designated operators under this bill are already doing most of the things this bill would enforce. However, if this bill obtains royal assent, a few major changes will take place.
Three major changes to cybersecurity under the CCSPA
If Bill C-26 becomes law as it stands, then we can expect three things to change: incident reporting, supply chain regulations, and the degree of direct control the government will have on enforcing cybersecurity measures.
1. Security incidents will become more transparent
The CCSPA will require any designated operator to immediately report any security incident that affects a CCS. The procedure and detail of such reports are yet to be determined.
The goal is to tighten the response loop when vulnerabilities and breaches are discovered. By requiring organizations to report incidents immediately, Canadian legislators hope to keep the public and private sectors unified in their responses to cyber threats.
2. Supply-chain security will be regulated
The supply chain has always been an effective way to breach large entities. Just like it’s easier to climb into a wooden horse than it is to directly climb the walls of Troy, it’s easier to breach a small software contributor than it is to directly breach an enterprise application.
This is why the CCSPA would formally increase security around designated operators’ software supply chains. Under this act, companies who operate critical cyber systems would need to immediately take “reasonable action” as soon as any threat or risk related to their third-party suppliers is discovered—including actions prescribed by regulators.
3. The government will compel companies to take security actions
This act wouldn’t simply change the status quo regarding responses to third-party vulnerabilities—it would also give Governors in Council the authority to direct any single designated operator (or class of designated operators) to take new cybersecurity measures. This may be in response to a known threat, or it may be preemptive.
How to prepare for C-26
If you operate in a vital class designated by C-26, or if you plan to sell software services to organizations that will become designated operators under C-26, it would be wise to start preparing for the CCSPA now. (And even if you don’t sell into these industries, keeping your systems secure is both smart and responsible.)
Talk (and listen) to the regulators
Specific requirements will be determined by regulating authorities, and discussions have already begun. Talk to the regulators who oversee the designated class you do business in—this will be your best source of information.
This is also your chance tobring ideas and concerns to regulators. The rules will depend on how diligent and well-informed the regulators of each sector are when the bill goes into effect—so if there are security measures you’ve found particularly effective, there are threats and vulnerabilities you find especially concerning, or there are proposed cybersecurity measures that could negatively impact other aspects of your business, now is a good time to make those known.
Future designated operators: begin analyzing your vendors’ software.
If you do business in one of the classes C-26 designated, you will need to take reasonable steps to protect your software supply chain from threats. A wise place to start is by asking your vendors for their software bills of materials(SBOMs). This will give you a full view of what code libraries your vendors used to make the software your critical cyber systems rely on.
Beyond obtaining your vendors’ SBOMs, now is a good time to analyze your vendors for vulnerabilities. You can do this easily with a software composition analysis tool like MergeBase, which allows you to analyze other organizations’ code for vulnerabilities, even if you don’t have direct access to that code.
Vendors to future designated operators: prepare your supply chain security documentation.
In order to continue doing business with designated operators, your software supply chain must be compliant with regulatory standards. You can expect your designated-operator clients to begin asking you for your software bill of materials.
This applies to you even if you’re not a Canadian company.
Therefore, you can take three actions to prepare for this bill to go into effect:
Assemble your software bill of materials. Compile a list of any third-party code you are using in your product, as well as any other third parties who have access to the code you sell.
Ask your suppliers for their software bill of materials. This will help you get a comprehensive view of all the contributors to your final product.
Analyze your entire supply chain for vulnerabilities. You can use an advanced software composition analysis tool like MergeBase to find and patch vulnerabilities in your own code as well as your suppliers’ code—and their suppliers’ code too.
Having your house in order will put you in the most prepared position when (or if) the CCSPA goes into effect.
All softwarecompanies:expect trickle-up cybersecurity standards to increase.
Even if you don’t do business with a designated operator, there’s a chance that one of your customers or partners does. If this is the case, it’s possible that they will pass their new cybersecurity standards on to their suppliers and partners.
Now is a good time to check if you’re part of a future designated operator’s supply chain. If you are, consider preparing your own SBOM. At the very least, make a plan for what to do if one of your customers or partners begins raising cybersecurity standards for you.
Pro-tip: You can use MergeBase to generate your own SBOM or the SBOM of any other software. Our customers tell us that our reports are more thorough and accurate than most in-house SBOMs—book a demo if you’d like to see how it works!
Mitigate third-party and supply chain risks with a software composition analysis (SCA) platform
Cybersecurity measures will only increase in the future. One way to prepare for legislation like the CCSPA is to implement our advanced SCA platform.
MergeBase allows you to analyze code for vulnerabilities as it’s being written, and it lets you check for third-party vulnerabilities in both your test environment and your live product. It also gives you the opportunity to automatically patch vulnerabilities in your software supply chain, which keeps you, your customers, and your users more safe from cyber-attacks than they otherwise would be.
If you want to raise your own cybersecurity standards ahead of C-26, schedule a MergeBase demo today. Our team will show you how you can begin protecting yourself from supply-chain risks now.
If you’re a developer (or work closely with developers), you’re likely already familiar with the concept of Shift Left Testing. This is the practice of testing your code earlier in the dev cycle rather than later.
Traditionally, software goes through the plan, code, and build phases before being tested. However, more and more organizations have recognized that holding quality assurance until the end of the process often leads to a lot of recoding and rebuilding—which takes up time and energy that could be put to more valuable use.
(The concepts of “left” and “right” in this discussion refer to a timeline: the earlier something takes place, the further “left” it shifts on that timeline.)
Shift Left Security refers to the practice of addressing vulnerabilities earlier in the development process. It’s a sub-practice of Shift Left Testing. Rather than testing code for vulnerabilities right before pushing it live, DevOps teams that shift their security left keep their code vulnerability-free as it’s being built.
Shift Left philosophy explained (a nontechnical analogy)
“Shift Left” may sound like in-speak to people outside the development world, but the philosophy of catching mistakes early is intuitive. In fact, anyone who has had to turn in a written homework assignment has benefitted from Shift Left thinking.
Imagine you’re turning in a final paper for a class. A portion of your grade will be determined by your use of grammar, spelling, and punctuation—and you lose points for every mistake.
If you approached this assignment using traditional Shift Right practices, you’d write the paper, then review the text for errors. This could be a big task, and even if you’re using a spelling and grammar check tool, you’ll likely need to re-read old paragraphs to make sure the suggested edits align with what you were trying to communicate.
However, most word processors today help you catch errors as soon as you make them. Red underlines tell you you’ve written a word that isn’t in the dictionary. Blue underlines tell you where you’ve mistakenly used “effect” instead of “affect.” And common typos like “teh” and “adn” are automatically corrected to “the” and “and.”
These word processors have “shifted left” the spelling and grammar check process. They flag and sometimes automatically fix mistakes as they happen. Not only do you finish your draft with fewer mistakes, but you also get to see what kind of mistakes you commonly make as you’re making them, ensuring you’re less likely to confuse “infer” and “imply” in the future.
Shift Left Security applies that same principle to catching vulnerabilities as early in the software development life cycle as possible.
Benefits of Shift Left Security
As you can imagine, Shift Left Security brings software companies a host of benefits.
Better use of dev time (and money)
By reducing the amount of recoding and rebuilding work, developers can focus their time on coding and building software that’s already cleared for security. This means more dev labor goes toward what you hired them to do: development.
Faster development cycles
In tandem with the previous benefit, Shift Left Security makes it possible for software to more quickly enter the deploy phase—which enables you to innovate and compete at a faster rate than you would otherwise.
More customer trust
By keeping software secure throughout the development life cycle, you reduce the chances of vulnerabilities entering the final product. Being able to innovate quickly and securely gives your sales team an advantage when selling to potential clients—especially when those clients are enterprise or highly regulated organizations.
Better team morale (and productivity)
Nothing kills morale like needing to start over. When you shift your security left, you reduce the number of times your team will need to do that—making their jobs less frustrating and more satisfying.
The problem: most vulnerabilities come from outside
Shifting security left helps you catch vulnerabilities early—but not all vulnerabilities come from the same source. While a static application security testing (SAST) tool can help you catch mistakes and vulnerabilities in the code your team writes, it won’t protect you from vulnerabilities that come from external sources.
And most vulnerabilities arise from third-party code. Unless your team builds 100% of your software from scratch, your final product relies on a mix of open-source libraries and code licensed from vendors. As these libraries are updated over time, people inevitably discover vulnerabilities—and these vulnerabilities can become security hazards to you and your customers.
These transitive vulnerabilities go through their own lifecycle, which can be described as four phases.
Most known vulnerabilities are found in one of three ways:
The source discovers the vulnerability themselves. One of your vendors might discover a vulnerability in their code via a routine security check, or during the process of making other updates.
White-hat researchers discover a vulnerability. Teams of “good hackers” regularly study other organizations’ systems in order to find weaknesses in their software. When they find a new vulnerability, they’ll usually alert the vulnerable library’s author. Instead of exploiting the weakness, their end game is to help find and patch them before …
… Black-hat researchers discover a vulnerability. These folks find and exploit vulnerabilities for their own agendas—usually to ransom companies for money, steal data, or cause mayhem.
Once a library’s author knows about a vulnerability, they’ll usually make an announcement so that people relying on the vulnerable code can take protective measures.
Some white-hat researchers will also take it upon themselves to alert people about known vulnerabilities. (Google’s Project Zero is an example of white-hat researchers who publish their findings.)
Once they’ve shared the vulnerability with people who need to know, the author of the vulnerable library gets to work on fixing the problem. When they’ve made a patch, the author makes the secured, updated library available to their partners and customers.
Fixing the problem within the source library doesn’t always automatically patch the vulnerability for everyone who was using the vulnerable code. Once the fix is available, everyone using the broken code still needs to implement it.
Sometimes this is as simple as updating from one version to the next, e.g., updating from App 2.3.1 to App 2.3.2. But other times, the fix is contingent upon other libraries and systems being in place—sometimes, implementing one fix can involve updating (or even upgrading) multiple other libraries.
Fortunately, it’s not necessary to manually keep track of new vulnerabilities and fixes—you can use software tools to do much of this work for you.
Using software composition analysis (SCA) to shift security left
Software composition analysis (SCA) tools scan your third-party code for known vulnerabilities. Depending on the solution you use, SCA can also direct you to appropriate fixes—and sometimes, it can even implement those fixes automatically.
SCA is still an emerging product category, and software companies can choose to use free or paid options. Both can help you shift security left, but paid options (including ours) have far more to offer when it comes to securing your development process.
Free SCA tools
Free SCA tools give you some ability to scan for third-party vulnerabilities in your build and testing environments. The benefit of using these is that they are, well, free. However, the two leading free SCA tools (NOM Audit and OWASP Dependency Check) come with a few significant drawbacks.
First, free SCA tools draw from limited sources. In order for an SCA tool to scan for vulnerabilities, it must have a source of vulnerabilities to reference—a list of canonical vulnerabilities to look for, if you will. The more sources an SCA tool draws from, the more comprehensive its vulnerability checks will be.
Both of the leading free SCA tools draw from smaller, more limited pools of known vulnerabilities, which means they cannot give you comprehensive coverage. (For example, OWASP Dependency Check solely references the National Vulnerability Database.)
Second, free SCA tools are notorious for false positives. Free SCA tools have a tendency to cry wolf, raising alarms for vulnerabilities that aren’t actually there. While it’s good to be vigilant about your application’s security, one of the reasons for shifting left in the first place is to make better use of your developers’ time. Sending developers down wild goose chases only to find false positives cuts into the time you would have otherwise saved.
While free SCA tools are better than nothing, the lack of development team power behind them means they have a hard time keeping up with paid options.
Paid SCA tools
Paid SCA tools (like MergeBase) allow you to shift left in far more powerful ways. A good paid solution will have several features and capabilities that free solutions simply can’t support today:
Multiple vulnerability sources. Paid tools reference multiple sources when scanning for vulnerabilities, so they have a wider range of issues to check for.
In-house research teams. Paid SCAs often employ teams of researchers to manually check up on the accuracy of the tool’s reports, verifying hits and minimizing misses.
Vastly improved accuracy. By combining the previous two capabilities, these tools tend to flag more vulnerabilities with fewer false positives.
Patch recommendations and (sometimes) autofixes. Paid tools provide sophisticated recommendations when it comes to addressing the vulnerabilities they find—and a few of them (MergeBase included) can even automatically fix some issues for you.
Most paid SCA tools will help you shift security left in substantial ways. However, they also strictly focus on the build and test environments—they aren’t typically strong at scanning your production environment.
MergeBase is the exception to this rule. Like other paid solutions, we scan your software in build and test environments. But we also analyze your live product for any vulnerabilities that emerge (and for many of these vulnerabilities, MergeBase automatically implements fixes for you).
Shift security left with MergeBase
Shift Left practices are common sense, but they’re not always easy to implement. At MergeBase, we’ve created an SCA platform that does the heavy lifting for you, so you can keep your code secure while you’re building it.
If you’d like to see how we can help you shift security left, schedule a MergeBase demo today!
You’ve been told that there’s a vulnerability in your software application. You’ve spent hours trying to find the problem. You’ve double-checked the alert. You’ve double-checked the software. No patches are available.
Finally, after ruling out every other option, you’re forced to conclude that there was never a vulnerability in the first place. You’ve just wasted your whole afternoon trying to fix a problem that wasn’t there.
This is the problem with false positives in software security.
False positives are false alarms—and each one can send you on a wild goose chase that costs your organization time, money, and emotional overhead.
That’s why it’s important to invest in security tools that reduce false positives. The more accurate your security software, the more easily you can mitigate the very real costs that false positives represent to your business.
We wanted to understand how false positives affect security teams, so in August 2022, we surveyed cyber security professionals on the subject. Twenty-nine individuals shared their thoughts on how false positives impact organizations.
Survey results: How software security professionals feel about false positives
We surveyed software security professionals on the costs of false positives, and the results indicate that false alarms are not only economically costly but also have long-term negative effects on the teams that deal with them.
In fact, given their businesses’ resources and constraints, most of our respondents would rather reduce false positives than increase true positives. False positives are a big problem in software security today.
This report will dig into these findings one by one, but here’s a summary of what our survey found:
72% of respondents believe that false positives damage team productivity.
62% of respondents would rather immediately reduce false positives than immediately catch more true positives.
62% of respondents also believe false positives damage overall team morale.
59% of respondents claim that, on average, false positives take more time to resolve than true positives.
55% of respondents believe false positives damage relationships between teams in their organization.
False positives, true positives, and the confusion matrix
A false positive occurs when your tool detects a vulnerability that isn’t really present. If you’re not familiar with statistical classification, it might be helpful to take a moment to get an idea of what we mean by “false positives.” (If you already know the difference between a false positive and a true positive, feel free to skip this section.)
You monitor the security of your software using various scanning tools, which check for vulnerabilities in your product. These tools might include static application security testing (SAST), dynamic application security testing (DAST), and/or software composition analysis (SCA). If a tool doesn’t find any vulnerabilities, it reports a negative—but if a tool detects a vulnerability, it reports a positive.
However, that’s just what the tool says. There’s the tool report, and there’s the actual truth: there either is a vulnerability (positive), or there isn’t (a negative).
In an ideal world, our tools would always match reality, but tools can make mistakes. If the tool report matches reality, then the report is true. If the tool doesn’t match reality, then the report is false.
To illustrate this mismatch, programmers use what’s (appropriately) called a confusion matrix. This compares the tool reports to the actual condition of your software, and it looks like this:
So there are two kinds of positives your software security tools are going to give you: true positives and false positives. True positives alert you to real vulnerabilities in your software. A false positive is a false alarm.
We queried software security professionals on this matter, and the responses indicated a consistent sentiment: false positives waste valuable dev time and damage team morale.
False positives take longer to resolve
When a scanner detects a vulnerability, the security team gets to work fixing it. If it’s a true positive, the issue is resolved when the vulnerability is patched.
However, if it’s a false positive, the issue can only be resolved when the security team can demonstrate that there’s no real vulnerability present. In other words, a false positive is only resolved once you can prove it’s a false positive.
We asked software security professionals which task, on average, takes more time to resolve: true positives or false positives. Of the people we surveyed, 58% said false positives take more time to resolve than true positives.
It follows that false positives generally damage team productivity. Because resolving false positives detracts from more useful activities (like building your software or fixing true vulnerabilities), false positives can put a good deal of drag on team productivity.
Our survey responses reflect this: seventy-two percent of respondents agreed with the statement that “False positives damage team productivity”—including twenty-eight percent who said they “strongly agree.”
Reducing false positives frees up dev time for things that actually contribute to your business.
False positives damage team morale, leading to vulnerability fatigue
In addition to the economic costs of false positives discussed above, false positives come with several soft, hidden costs. Our survey brought several examples of this to the surface—one of which was the sentiment that false positives erode team morale.
While this sentiment isn’t as pronounced as the sentiments discussed earlier, responses do skew toward agreement with the statement, “False positives damage overall team morale.”
This erosion of morale can lead to “vulnerability fatigue” or “patching fatigue”—which happens when a team becomes desensitized to vulnerability alerts (whether they’re true or false positives doesn’t matter). An abundance of false positives can weaken even the most zealous team’s motivation to patch vulnerabilities.
And once that attitude works its way into your operations, it can be very, very difficult to reverse.
False positives can damage relationships between teams
A slight majority of respondents agreed that false positives damage relationships between their teams and other teams within their organizations.
From an internal political perspective, false positives can easily undermine a security team’s credibility.
Security teams are already fighting an uphill political battle:
Teams dedicated to security usually aren’t building the product. In some organizations, “builders” can see the security team as lower-status contributors, non-contributors, or even a net negative to the business entirely. False positives can reinforce this mindset.
Security teams have the thankless task of pointing out where other teams made mistakes. People generally don’t like hearing about how they messed up, and so your other teams have a built-in psychological incentive to discredit your security team. False positives can perpetuate the narrative that security is either not credible or incompetent, which makes it more difficult for them to be taken seriously when a true positive comes along.
Unfortunately, because false positives take more time to resolve than true positives, other teams are more likely to remember false positives. Even if most alerts turn out to be true positives, it doesn’t take many false positives for a security individual or team to get labeled as the proverbial boy who cried wolf in the office.
Drive down false positives with MergeBase SCA
False positives are an unfortunate side effect of vigilant tools, but you can reduce false positives by investing in high-accuracy vulnerability scanners.
At MergeBase, we’ve built our software composition analysis tool with accuracy in mind. When customers switch to us, they commonly report a significant decrease in false positives and an increase in true positives.
For example, many of our customers are former users of OWASP Dependency-Check, a free SCA solution. Dependency-Check was built to be a super-vigilant vulnerability checker and therefore has a bias toward positives—including false positives. When companies upgrade to MergeBase (a premium SCA), they see an immediate decrease in false positives.
If you compare MergeBase’s performance against OWASP Dependency-Check’s on a set of libraries pre-seeded with publicly-known vulnerabilities (like this one), the difference in false positives (and true positives) becomes abundantly clear: MergeBase catches more vulnerabilities while reducing false positives.
We’ve built a tool that catches more vulnerabilities and sounds fewer false alarms when it comes to scanning your software supply chain—and if you’d like to see how it can help mitigate the costs of false positives for your team, we’d love to give you a demo!
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!