Security experts are always looking for a silver bullet. New products promise to resolve all your issues. Typically, these products overpromise to expand market share. Most attacks we see these days occur not because of genius attacks. Instead, they’re due to the company not following the simplest defensive practices. Keeping patches up-to-date and having strong password policies are still important. One of these often overlooked practices is software composition analysis (SCA). Let’s look at how SCA works and why it’s so important.
When you build any piece of modern software, there are a lot of components that aren’t completely yours. They might belong to an application programming interface hosted in the cloud from a third-party service. Or, they might come from an open-source library or a commercial library. SCA is key in these cases.
Don’t Neglect Software Composition Analysis
All of us talk about developing software, but we really write only 10% or 20% of that software. The rest are mainly imports and references or other modules that we have used. These are all third-party code. That fact generally becomes the major factor in attacks as well as risks.
Most of the new software languages provide package module options. Major new programming languages like PHP or Python also provide options such as modules to manage and build software. Therefore, you may use at-risk modules, outdated modules, discarded modules or all three. You can use software composition analysis to detect exposed and obsolete third-party libraries.
If you are using any commercial or open-source library, you must check for known vulnerabilities in your components. If you find an at-risk version, you should change or update it to the fixed version.
At present, there are lots of components in software that are based on open source and consist of many functions. We have seen with the Heartbleed bug that most people add OpenSSL into their apps rather than create their own encryption layer. But the ideal approach should be to understand what kind of components you are using and whether they are safe or at risk.
A software composition analysis tool looks for known components, sweeps through the code and finds existing risks. (The National Vulnerability Database and Common Vulnerabilities and Exposures (CVEs) hold a publicly-reported list.)
Can Software Composition Analysis Replace SAST?
Static code analysis, or SAST, is security testing done on source code or binaries without executing the code. Thus the term ‘static’ testing.
SAST is white-box security testing using automated tools. It is useful for identifying low-hanging vulnerabilities like cross-site scripting, Structured Query Language injection and insecure libraries. But SAST tools are mostly generic, meaning they need manual tuning and training for managing false positives. SAST looks for new problems, not for the already known issues. It can find both vulnerabilities and weaknesses in the code by searching for patterns and, at the same time, enforcing secure software coding standards.
Software composition analysis is vital to use alongside it. If you are not doing so, you are missing a lot. However, you shouldn’t expect it to resolve all issues. SCA fills a gap; it doesn’t replace the existing tools and process of SAST. SCA finds the open-source software packages in the application and checks for the already known risks in the installed version of components. It doesn’t check for new risks like SAST.
The Importance of DevSecOps
What is DevSecOps? Basically, it is a process where you strive for ‘secure by default.’ To achieve that, you start with adding security tools into the continuous integration and continuous delivery (CI/CD) pipeline.
The next step is to implement a security-as-code culture. When security testing is added into the software development life cycle, fixes are made for issues as soon as they are found without obstructing and repeating the development process.
Promoting cross-training among developers, operations, and security teams helps with this. Instead of having three different teams, there will be a single unified team taking care of all three components. That’s the aim of DevSecOps, and it dovetails nicely with what software composition analysis does.
The main problem with DevOps culture was that people working in the CI/CD pipeline often left security for last. With DevSecOps, now it is easier for everyone to make security a part of the development and deployment process.
Shifting security toward the left side of the CI/CD pipeline saves time, money and effort. For example, if a risk is found in the later stage of the CI/CD pipeline, by the time it is reported back to developers it will cost a huge amount of time and effort to fix. Instead, you should shift left in the pipeline to the Build Phase, where you have configured software composition analysis and SAST tools. That way, as soon you find an issue you can start fixing it. This saves everyone’s time and effort.
Source: IBM
Better Software Composition Analysis for More Secure Systems
The SCA and SAST tools perform different functions that complement each other. It is important to look for the problems in the code or component version you are using to make sure that you’re up-to-date and there are no CVEs or known open issues that have been found in previous versions.
You should always do both in software development, unless you write all of your own software. There are many free software composition analysis and SAST tools. You should also be scanning all the code you write for things like the Open Web Application Security Project Top 10 or the CWE Top 25 vulnerabilities and maintaining secure coding standards. With software composition analysis and SAST, you can uncover problems before they start.
The post Software Composition Analysis: Developers’ Security Silver Bullet appeared first on Security Intelligence.
