What is SCA security?
It’s similar to your home’s security.
SCA stands for Software Composition Analysis, although, this could be more confusing than the acronym.
One hint is in the word composition which can be defined as “the nature of something’s ingredients or components; the way in which a whole or mixture is made up.”
Thus, SCA == an analysis of software and all its components.
Software components can be divided into two categories:
- open-source code
or
2. proprietary source code
In today’s world, open-source is ubiquitous. In fact, up to 90% of applications are open source. Proprietary code has fallen by the wayside because of its lack of ability to keep up with the speed that open source enables.
Proprietary source code takes longer and investors don’t like to wait. In the world of quarterly business reviews, speed to market is a # 1 priority.
This isn’t a fad either. According to a recent report, 2020 saw a 259% increase in open source components from 2016. In 2016, there was an average of 84 open source components per application and in 2020 this increased to 528.
What’s more, according to this same report, 91% of codebases contained open source components that hadn’t been touched in the last two years.
This leaves us vulnerable. As the economist, Thomas Sowell says, “There are no solutions. There are only trade-offs.”
The trade-off is — open source code has the ability to meet the speed and innovation needs of technology investors but this comes with a cost. That is — as we increase the number of open source components to our applications, we increase the need for upkeep and we also increase the surface area for security vulnerabilities.
Insert SCA security.
What is SCA security?
It’s the intersection between innovation and vulnerable code. As we grow our open source code to innovate faster, we have to grow our ability to scan that code for security vulnerabilities.
Insert open source scanning software.
What is open source scanning software?
AppSec teams find vulnerabilities by using open source scanning software (aka SCA tools) by scanning an application’s open-source components.
But, this type of scanning has been known to generate an unmanageable number of open source vulnerabilities.
And, not all vulnerabilities are equal.
To give an example, ShiftLeft did an experiment in 2021 that scanned 49 applications which resulted in 2,761 open source security vulnerabilities.
I don’t know about your dev team, but if I submitted 2,761 security tickets to our team they may change their LinkedIn status to “Open to work.”
The reason SCA tools find so many security vulnerabilities is because they aren’t looking at “data flow.” Or, they aren’t taking into account how the open-source components interact with the custom code.
By scanning the components without the context of the application, you will spend time addressing known vulnerabilities that do not actually create risk for your application.
SCA security is similar to your home’s security
Imagine doing a hardware composition analysis (HCA?) of your home’s security. As you scan your home, it finds 10 doorknobs, and you discover six that are vulnerable. You are alarmed, so you immediately reach out to your contractor to fix them.
But, as the contractor looks closer, they realize that one door is a closet, another is a bathroom, one is a storm door, and the last one is a backup door being stored in your garage. All of these doors are obviously not security threats. Some of them are not even attached to your home and none of them can even be reached by an attacker.
Now, let’s apply this analogy back to software. As you scan your open source components, you find six open-source CVEs (Common Vulnerabilities and Exposures) in your application. You are alarmed, so you quickly assign these to a developer to fix.
But, as this developer looks closer, they realize that only three of these open source components are “attacker reachable.” This means an attacker can enter data into the application in a way that its malicious elements will be used by the open-source code and deliberately exploit the vulnerability.
In our home security analogy, these would be your bathroom, closet, and storm doors. They aren’t reachable to an intruder from the outside so they pose less of a risk.
Then, you find that one of these open source component’s APIs is not even being called by your application.
In our home security analogy, this would be the backup door stored in the garage. It obviously isn’t a security threat.
In software, attacker-controlled paths are determined by tracing an application’s public inputs (or sources) to sensitive sinks (db, log, http, etc.).
The analysis of the entire application, and how custom code interacts with open-source components, is critical when determining if vulnerabilities are attacker reachable. Any SCA tool that limits its analysis to merely the list of components, and not the entire application, is wasting developer time and investor dollars.
Therefore, your SCA tool needs to be smart in how it does its analysis. It has to have a systems-thinking approach. You could say, it needs to be intelligent.
Thankfully, I just happen to work at a company that has an intelligent SCA tool. It’s called ShiftLeft Intelligent SCA (I-SCA) and it introduces this novel concept of “Attacker Reachability.”
I-SCA prioritizes your OSS vulnerabilities based on how vulnerable and attacker-reachable they are to your application.
Based on testing conducted against other commercial solutions, Intelligent SCA reduced open source vulnerability tickets by 92%.
The #1 performance measure in AppSec is “how many vulnerabilities are getting fixed and how quickly.” In our newest report, we demonstrated that ShiftLeft customers who automate code security in their CI/CD pipeline are fixing 91.4% of new vulnerabilities.
Don’t take our word for it. Check out the new report or just sign up for free and test drive it yourself over at www.shiftleft.io.
