Achieving Effective Open Source Security & Management
With the use of open source exploding worldwide, organizations are searching for the best way to secure it and manage it. There are a variety of ways to approach the task — and in a crowded security-provider market there is a lot of confusion about which methods are most effective. Whatever way you go, it’s good to keep a few open source security truths in mind.
Truth #1: If you’re going to scan, capture all the open source
To identify all of the open source you need to look at all of the code. Analyzing and matching libraries, files and directory structures is extremely precise and the most effective way to identify all the open source in use (and consequently report all known vulnerabilities).
Simpler approaches, like POM file analysis, see only what is declared or required for the build – not necessarily what is actually used – and don’t scan files for matches. For example, a POM file can specify minimum versions for certain components — the actual version that will be pulled into the build and part of the final product may be the minimum version or it may be a much newer version. Likewise, it will likely not capture transitive dependencies, i.e., other components that are themselves dependencies of those components specified in the POM file. A partial listing leaves organizations blind to the risks in their code – a problem security professionals don’t need.
If you need visibility into your open source vulnerabilities (and you do), make sure you have visibility to all of it. After all, that’s the point of the exercise.
Truth #2: Scanning can enhance the agile SDLC process
Agile environments require timely information. When open source scanning is part of a secure sdlc process, identification of all the open source used and vulnerability detection takes place early in the SDLC, when remediation costs are minimal. Scanning provides an updated inventory, or bill of materials, with each build. That’s agile.
Additionally, policy creation and enforcement enhances scanning efficacy, helping developers make informed open source selection to avoid using components with known vulnerabilities or inappropriate licenses before development begins. That’s agile too.
Truth #3: Re-scans aren’t always necessary when new vulnerabilities are disclosed
The most effective open source scans create and maintain an inventory, or bill of materials of all the components identified, and map all known vulnerabilities to those components, and the inventory is saved. Coupled with continuous vulnerability management, when a new vulnerability is disclosed, organizations can generate alerts and quickly identify all applications using the now-vulnerable code.
Truth #4: Automated identification is effective and economical
Automating the processes for identification of open source in use, mapping it to known vulnerabilities, and tracking new threats is far more effective and much less expensive than doing so manually.
File scanning, and matching components and directory structures to a database of open source projects, can be efficient and fast if you have a robust database to support it.
Do the math. Make sure your solution will provide you with effective open source security and management.