This is the second installment in this series on DevSecOps. Read the first installment, on Static Analysis, here.

Related Topics

One of the better additions to security in recent years is source composition analysis (SCA). The purpose of SCA is to sit in the gap between static analysis and dynamic analysis to help you find issues introduced by included libraries, projects, etc. While effective, source composition analysis is only available on open source libraries and packages, which are the highest growth areas of external sources in any project. If we are purchasing a product to include in our application, we take our time and compare and contrast to make certain we have the right thing. If there is an open source option, we just drop it in. Particularly if the option is popular—little thought goes into using MySQL database in Python or its equivalent in other languages. If a Python project uses MySQL or MariaDB, it is needed, so it is grabbed and used.

The growth of source composition analysis is a great boon to security. Having a tool that takes care of monitoring vulnerabilities in code that is included across the board, sometimes in very uncontrolled ways, means vulnerabilities are known before the app goes live or the new release is published. Security staff doesn’t have to try to ferret out what is included in projects across the org and then cross-reference those findings with the National Vulnerability Database (NVD) or project-specific lists. The tool takes a load off security’s shoulders and makes certain developers know the risks their open source software (OSS) usage represents. The best tools notify developers when including vulnerable open source and can be configured to require approval before a vulnerable OSS library/module can be included.

With all of that said, let’s talk about what to look for. There are some similarities with our static analysis list, but some distinct differences also. Disclaimer: As mentioned in the Static Analysis blog, this is very high-level. The research we’ve done at Accelerated Strategies Group went much deeper than we can present in a series of blogs; this is just to help you understand the top-level issues and get started down the road to a solid DevSecOps plan:

Language Support: This goes beyond most users’ needs in static analysis. One of open source’s strengths is building off other projects. It is often the case that Python will call C modules and some Python projects even include Go libraries. This means your chosen development tools aren’t so much relevant for scanning as the development tools chosen by projects—and their included projects.
Depth of Checking: Which brings us to, “How deep does the tool go?” Nesting of open source libraries can be deep and complex, with the project an application uses directly just the tip of the ice-berg. Ideally, look for a tool that answers the, “Is this even ever called?” question. It’s a good start to alert on included OSS projects and it is far better to alert on ones where the vulnerable parts are called from somewhere in the hierarchy.
Where to Run: The market is slowly moving to support both cloud-based and local scans. Make certain your organization’s needs are met by the vendor’s offerings.
When to run: Some vendors bundle source composition analysis in with their static analysis IDE plugins; others have developers run the scan command line; others offer source composition analysis at the build step—when the app is together in one place; still others offer all of the above. Again, make certain the needs of your organization are met.
What Is Detected: As with most security tools, this is normally a base comprised of public sources (NVD, OWASP), with add-on detection from other sources. Know what those other sources are and what they offer: that is one major difference between most products.
Reporting: Make certain that vulnerability reporting has everything you need. Consider the possibility that it alerts on a vulnerable OSS library in source file insecure.go. All other uses of that vulnerability need to be visible in some way from that report. Removing the reference from insecure.go is useless if reallyinsecure.go also includes it and has an exception from management to keep the inclusion.
Reporting Integration: While scanning OSS usage and vulnerabilities the usage introduces is important, so also is the ability to see these results side by side with static, dynamic and even interactive scans so the overall security posture of the application can be evaluated.
Frequency Versus Cost: OSS vulnerabilities come in unpredictable patterns, with several dropped in a week after no important ones were seen the week before. You are going to want to run these scans frequently enough to feel comfortable with your security posture, but depending upon licensing, each run might cost your company money. Make sure you understand your needs and costs associated with meeting them.
Licensing: The newest feature to be added to these tools is the ability to list all licenses of all included libraries so that someone can review and see what risk is introduced to the organization from licensing. Many open source projects are licensed so that commercial use is limited; this tool puts all the various licenses together so an organization can evaluate litigation risk based upon license usage. The best tools allow you to also enter proprietary license information so that all licensing relevant to an application is reviewed together.

These tools help improve security posture by automating what is an increasingly complex manual process and bringing in vulnerability sources that security (be they secure developers or dedicated security staff) would have to manually look for. They enable shifting OSS vulnerability resolution left, allowing your team to become more agile and proactive. Make certain the tool chosen is the right one for the organization.

As I said in the last installment, you all are keeping the lights on in a truly difficult time, making a tough job look easy. Don’t let vulnerabilities that can be caught easily with these tools but might stay hidden without stop your great work. They are relatively easy to install and configure; once you have them, you have on-demand OSS vulnerability scanning and if you are like most organizations, OSS is a huge piece of your software infrastructure. Keep rocking it, and make sure you are covered for OSS vulnerabilities and licensing.