The term Software Composition Analysis (SCA) is relatively new to the security world. But similar approaches have been used since the early 2000s to indicate security verifications on open source components. SCA has become an evolution of that. It is the process of identifying and listing all the parts and versions present in the code and checking each specific service and looking for outdated and/or vulnerable libraries that may impose security risks to the application. These tools can also check for legal issues regarding the use of open-source software with different licensing terms and conditions.
But how those SCA tools work, and how can they help identify and remediate issues on open source libraries that are being used in your codebase? Well, first, to be able to generate a graph of the components that are part of specific software and any issues related to them, we need to rely on at least three pieces of information:
Application Manifest – a file that gives instructions on how the software should work, provides a list of dependencies required and contains required permissions and version compatibility.
Vulnerability Data Sources – a database of vulnerability information, they can be private or public, the most common public one is the National Vulnerability Database (NVD)
Dependency Metadata – it is the metadata related to the dependencies you have on your code, such as version, packaging, license, etc.
With the information above, you can better understand how your application is built and its open-source software. You can also identify which libraries are outdated or have a known vulnerability in them. Ok, that’s great! But there are some other rather complex issues that you need to be aware of when applying this technique or using an SCA tool to identify the problems on 3rd party software.
First, there are the direct dependencies, which are the ones you call directly in your code. Those are easier to list, identify their versions and fix. But then, they can also depend on other libraries that they use, and so on. These are called indirect or transitive dependencies. If those are outdated or vulnerable, it will be hard for someone to fix them directly unless they are the owner or maintainer of that code.
Second, it is ubiquitous for security researchers to make a vulnerability public by creating a CVE and providing details on how the attack works and how to fix it. But in the open-source world, not every vulnerability gets a CVE. Why? Mainly because the CVE process is prolonged and centralized. Usually, there is no benefit for a developer to report a security bug unless they need someone to fix it for them.
And last but not least, the effort to remediate those issues found on 3rd party software is much higher than the effort to identify them. It requires the execution of a series of unit and regression tests to ensure that everything is still working as intended and that most of the time either doesn’t exist or isn’t automated.
In a nutshell, SCA tools and techniques are here to stay, and their usage is increasing in many organizations where security is a priority. AppSec teams can’t keep up with all the new vulnerabilities being published daily. Make sure to look for solutions that can adequately adapt to your own way of building software. They need to cover the programming languages used in your organization and identify indirect dependencies, not just relying on public CVEs to find those issues.
Lately, we’ve been hearing a lot of discussions around the use of DevOps and DevSecOps. Although these are considered very good practices, I believe many organizations aren’t doing it properly or even aren’t prepared for them just yet. These practices demand many cultural changes in organizations, which most of them aren’t prepared for or are welcome to changes. Just using tools and automation is not enough to achieve the cultural change needed. Many researchers and authors believe that DevOps itself already includes security in its core and although they may be right since software security is closely related to software quality. Unfortunately, that’s not the case in most of the companies adopting DevOps yet.
Many organizations are applying DevOps without thinking about Security. That’s why, I believe, a new term was created, first called Rugged DevOps, or SecDevOps, or DevOpsSec and lately DevSecOps (other terms you may found out here are Agile Security, Agile SDLC or DevOps Security). The goal of DevSecOps, in my opinion, is to raise awareness of the increasing need for security in this shifting culture using the agile and automation mindset. DevSecOps is an evolution to DevOps to make sure that security teams stop being the bottleneck for digital transformation.
DevSecOps is changing the Application Security industry by integrating security verifications and checks within the development process and reducing the vulnerabilities found before launching into production. According to Gartner, here’s their definition of DevSecOps:
“DevSecOps can be depicted graphically as the rapid and agile iteration from development (the left side of Figure 1) into operations (the right side of Figure 1), with continuous monitoring and analytics at the core. Our goal as information security architects must be to automatically incorporate security controls without manual configuration throughout this cycle in a way that is as transparent as possible to DevOps teams and doesn’t impede DevOps agility but fulfills our legal and regulatory compliance requirements as well as manages risk” Gartner – DevSecOps: How to Seamlessly Integrate Security Into DevOps
Currently, security testing is generally performed at the end of the application development process, which increases the risks of deployment delays and project costs. Especially if vulnerabilities that require recoding or redesign are found. Companies can overcome this problem by using the “Shift Security Left” (SSL) approach, which according to Accenture and AWS basically says that it “introduces security at the inception of the development lifecycle and automates testing within the DevOps workflow.” Please don’t confuse that approach with the SSL/TLS encryption protocols. Let’s discuss some of these practices and how you can apply them in your software development scenario.
Outdated and vulnerable libraries (SCA)
One of the biggest problems related to security that organizations face is knowing what’s exactly inside their applications and how to properly and securely patch them. We can all remember the damage that was caused by Wannacry in 2017, which exploited a vulnerability that was fixed three months before the attack was launched. In the same year, Equifax was also breached, in another big attack that was news all over the world, because of an outdated and vulnerable version of the Apache Struts library, which allowed the execution of remote commands on their systems4.
Nowadays it is very rare, if not never, for a developer to write code from scratch, meaning without using any frameworks or libraries. And that also has become a big problem on applications since most of the code being used comes from third-party and is rarely verified or tested for security issues. Recent studies have shown that more than 90% of applications are made up of open source and that 70% of those are outdated or have a public available vulnerability. The OWASP Top 10 2017 addresses this issue in its A9 – Using Components with Known Vulnerabilities:
“Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defences and enable various attacks and impacts.” – OWASP Top 10 2017
A great example of this issue is WordPress, a famous CMS system that has a strong and well-tested core, at least nowadays, but its themes and plugins are very problematic and unreliable since they are developed by third-party developers that don’t always follow the same security procedures and verifications in their development process as the core WordPress team.
There are many tools out there that check for outdated software on servers and even update those for you. But that’s not an easy task especially because of the incompatibility issues with legacy applications and the lack of proper regression testing to make sure everything is working properly once the updates are made. That becomes even harder when the outdated library is embedded in a custom or in-house application and the tools mentioned earlier won’t work on them. So, what can be done is to verify these issues before the application is even built, generally during the development phase or during pre-build tasks.
There are many tools available that will perform those tasks for you in many different languages and frameworks, some of them can even be integrated into your developers’ IDE and they check and fix these issues before submitting any new code. OWASP has a great free tool available for Java and .NET libraries called OWASP Dependency Check, which also has plugins for CI tools like Jenkins. Other commercial tools that can help you in this process are Snyk, WhiteSource, Synopsis BlackDuck, Veracode SCA, Conviso AppSec Flow and Sonatype Nexus IQ Server.
Automated security scans (DAST)
As we mentioned before security scans are mostly performed at the end of the application development process, usually after the application has been done and it is properly working at least on a Dev or QA environment. So any issues found would either need a system update of some kind or recode to fix the application. It has been proven on many occasions that fixing bugs earlier in the development lifecycle is much cheaper and faster than after the application is in production. So why not run our security scans as soon as possible to find the problems at an earlier stage?
With virtualization, containers, orchestrators and serverless it has become very quick and easy to create and destroy environments for testing or proof-of-concept (PoC) purposes. Security teams can use those techniques to create temporary servers to be tested with the new updates as soon as possible and make sure their applications still work. You can also integrate security testing in the build process, so every time a build is generated and all those Q&A testing is done, some security testing is also performed, giving fast feedback for the developers to fix it. Another great tool from OWASP is OWASP ZAP, which is a web proxy, and like Dependency Check, it also has a Jenkins plugin to integrate your security scans in the build process. Other tools that can help you in this process are w3af, Arachni, BurpSuite Enterprise, Acunetix, Netsparker, WebInspect, AppScan, Conviso AppSec Flow and Veracode. For a full list, please check the OWASP Vulnerability Scanning Tools list.
Security code reviews (SAST)
Code reviews and refactoring have been in place for a long time, but mostly focusing on code quality and performance. Security code reviews focus on vulnerabilities and security issues, regardless of how the code has been written. Although there are many tools available already, there are also many different languages and also false positives to deal with. In the DevSecOps mindset code reviews should be done at each commit, preferably automated since the objective is to commit small pieces of code many times a day or a week, to make sure that if something happens, it would be easier to debug and fix. In that case, you can integrate your security code review tool with your SCM and create alerts or even triggers that execute a scan in your source code every time there is a commit to your SCM.
Performing those checks frequently will significantly reduce the number of vulnerabilities in your software after deployment that would need any code change. It will also give your developers fast feedback about the mistakes they are making and how to avoid them. Some tools to help in this process are Checkmarx, Fortify, HuskyCI, Horusec, AppScan, SonarQube, Conviso AppSec Flow, and many others. Please check out this detailed list of Source Code Analysis tools by OWASP for more options.
Developers are not security experts, they rarely hear or learn about security during their learning, so don’t expect them to understand and fix all the security issues at once. This process takes time and requires training. The security team has to understand how the development flow works and try to include security in a way that is transparent and fluent, without adding new barriers. Try to use security verifications and checks inside already well-known tools like IDE, CI/CD, SCM or ALM tools using add-ons or plugins.
Applying those three practices effectively will have a huge impact on the security of your overall applications. Make sure you automate those tasks as much as possible so that your security team can focus more on manual testing and other issues and the developers can have fast feedback about the security of their applications to take action. Remember what matters to the business and try to balance security with new features.