Speed is all we need. The faster developers get versions to production and solve security issues that inevitably crop up, the sooner businesses can reap the benefits of their new product. Shifting left is one popular approach that aims to solve security issues as early as they arise - limiting deployment delays. 

Between 2019 and 2022, the number of software packages affected by supply chain attacks worldwide jumped from 702 to a staggering 185,572. If the need for speed isn’t enough for businesses to put security at the forefront, the increasingly high risks of supply chain attacks might be. 

Among the various tools and technologies that make shift-left security possible, Software Composition Analysis (SCA) stands out as a critical enabler. This article explains how SCA works and offers practical advice to help you get the most out of your chosen SCA scan tool. 

A quick analysis of Software Composition Analysis (SCA)

Software Composition Analysis (SCA) scans your open-source software (OSS) components and libraries to help ascertain whether an application, code base, container, or binary contains known security vulnerabilities. It spots these vulnerabilities by analyzing the product’s dependencies (name and version used) and comparing them to known vulnerability databases. Similarly to SAST and DAST scans, SCA can flag vulnerabilities based on risk and severity, making it easier to know which issues to prioritize.

You can carry out SCA manually or with the aid of automated tools. Due to the number of open-source packages and potential vulnerabilities involved, manual open-source software composition analysis is not scalable. 

To do it manually, engineers would need to examine a vulnerability database like NVD (National Vulnerability Database, managed by NIST) and compare it with their current dependencies. NVD updates its “year” feeds once a day, while the “recent” and “modified” feeds are updated every two hours. This means your engineers would have to update their dependencies just as frequently. Utilizing automated SCA security tools, which you can manually activate or incorporate into the CI/CD pipeline for continuous inspections, is far more efficient. 

While SCA doesn’t directly prevent cyber attacks, it helps you address issues before they can be exploited through attacks such as SQL injection and Cross-Site Scripting (XSS). For example, with XSS attacks, SCA can flag third-party code imported from libraries, that doesn’t validate or sanitize user input, a common cause of XSS vulnerabilities. 

7 Tips for an Effective SCA Scan

1. Know what’s in your code 

SBOM (Software Bill of Materials) is a byproduct of many SCA tools, but even if your tool doesn't create one, there are free, open-source tools (like Syft) you can use to make one for your product and keep it updated. Once you have a solid SBOM, use that list of components to track new vulnerabilities, newer versions of packages, and packages that have reached end-of-life or are no longer maintained. 

You can use this component list to check against known vulnerability databases using a free tool such as OSV Scanner. Even if your next product version is not yet ready, you might already be able to provide developers with security updates on components they have previously included. Below is an example of the software component inventory SBOM tools can produce: 

2. Make sure the tool fits

Each language and potentially even build system could handle component listing differently. Therefore, ensuring your chosen SCA solution supports your coding languages is crucial. 

Most SCA tools rely on manifest and lock files such as Pipfile.lock, Package.json, or package-lock.json to find components and their respective versions. Remember that if you’re using a language not covered by your SCA tool, you’ll never find any vulnerabilities in it since your tool won’t be able to check it properly. 

3. Use SCA throughout the SDLC

Any security issue you find later in the SDLC stage usually requires getting the code back to development for correction, a.k.a it’s a huge time waster. Therefore, we want to get as clean a version of the application as possible into the CI/CD pipeline. That’s why your SCA tool should be easily integrated with your developer’s IDE (Integrated Development Environment) and run without increasing the developers’ overhead too much. Jit has an IDE Extension for Visual Studio Code, one of the most popular IDEs. Here’s what it looks like:

Even if you run SCA scans early in development, you can’t trust that all scans will run adequately. Placing SCA at the end of your SSDLC will help you perform a final check to ensure no vulnerabilities cropped up in earlier phases, contributing to a more holistic security strategy and giving you more confidence in the safety of your software. 

4. Automate scanning 

We’re all busy, and, as we saw earlier, issues may fall through the cracks. It’s not just about not trusting people’s memory but ensuring that the scans are as efficient as possible, contributing to your overall DevOps automation strategy. Whatever SCA tool you choose, verify that it can be automated to run both at the IDE and CI/CD levels. For example, Jit’s SCA platform can be automated to run on every new PR with no added commands. Each security finding would show in the pull request conversion, as seen below: 

Here’s an example of a JIT vulnerability scan as expressed in a YAML file:

namespace: jit.code

name: Detect code vulnerabilities

description: |

  Static code analysis tools can discover vulnerabilities inside your code before they make their way to production.

summary: |

  Integrate SAST into CI/CD so it automatically runs for every new PR

workflows:

  - uses: jitsecurity-controls/jit-plans/workflows/sast-workflow@latest

tags:

  layer: code

  risk_category: code_vulnerability

  compliance:soc2: CC7.1

5. Diversify your scans

Different databases may use other names for the same component. Because not all SCA tools use the same database, one vulnerability may be detected with one tool and missed with another. This is why an SCA solution like Jit’s, which combines coverage from several SCA tools like OVS-scanner, npm-audit, and Nancy, is a good option if you don’t want to put all your eggs in one security basket.  

6. Integrate with Issue Tracking

Getting a JSON file at the end of your scan with a list of potential vulnerabilities is all well and good. Still, it won’t see heavy use unless easily integrated into the company’s task management system. Whatever tool you use to track issues and tasks for your security and R&D team, be it Monday, Jira, or Confluence, arrange for your SCA results to be automatically sent to the proper team or person. It helps if your tool also offers remediation suggestions for each vulnerability. 

Jit enables you to send your test results directly to Jira. By modifying your jit-integration.yml file (adding your API token and relevant JIRA data to this file), you can integrate your Jit scanning results seamlessly with Jira. Here’s what the yml file template looks like:

jira:

  jira-engineering:

    auth:

      api_token: ${{ jit_secrets.jira-token }}

      email: requester@company.io

      domain: extract_from_jira

    preferences:

      project_id: 10001

      issue_type_id: 10002

      fields:

        customfield_10034:

          - value: "1"

‍

7. Create security policies for your SCA 

Whether or not the SCA tool you integrate knows how to handle security policies, you should create those yourself and apply them to the scan results. The more granular you can get in using the SCA information, the better for your users. As an example, Jit provides enriched findings combining the results from several tools, so you’re more likely to find valuable insights you could use for such policies. Some examples of policies might include:

1. Do not allow any open-source license that is not permissive.
2. Do not allow a build to be distributed with high or critical vulnerabilities.
3. Do not allow a component with a known vulnerability and a known patch that you can fix (why fix it later when you can fix it now?).
   

Post-SCA: Optimizing application security at all stages

Whether done at the coding stage or in your CI/CD pipeline, SCA scans are just the beginning. From your CVSS score to your EPSS probability, you’ll likely end up with overwhelming information and hundreds or thousands of potential vulnerabilities. All this helps guide you in the monumental task of deciding what to tackle first.

Vulnerabilities come and go; that’s the name of the game. Find a strategy to optimize your team’s time and keep your product as safe as possible. You may not be able to ship an entirely bug-free product, but you can aim to at least ship a non-exploitable one. 

No matter which tool you employ, integrate SCA scans throughout your pipeline and enrich the findings from SCA scans with insights from other security tools. Jit’s DevSecOps platform can integrate with various open-source security tools to give you a holistic view of your security posture. Explore more here.