A vulnerability is usually an unintended software bug that opens an attack angle for a malicious actor. The good thing about an open-source project is, that the bigger the project, the more eyes are on it. The more likely these vulnerabilities will surface and be fixed fast. In smaller or dormant projects, this is usually not the case.

A supply chain attack is a deliberately created attack against a language ecosystem or certain users.

Recently, very targeted attacks have been seen against the fintech sector.

The attackers would use various different techniques to spread the malicious code. From simple typo squatting - where you publish a new package with a common spelling mistake - to sophisticated attacks - where social media profiles are created to build trust with the community and victims - the range is wide.

How can you protect your applications from either?

As discussed last week, lockfiles are an essential part of detecting attacks. There is more that can be done. A variety of open-source and commercial projects review the required dependencies. Then they compare the versions with various data sources to identify if you have a vulnerability in your dependencies.

Make these tools part of your workflow. Add them:

  • your Local development
  • the CI/CD pipelines for every merge request,
  • running in your live systems to detect new vulnerabilities that are actively in use.

These exact tools also help you identify known vulnerabilities in your dependencies.

The moment you enable tools like this, the chance is high to get a lot of findings as a result.

How to triage vulnerable dependencies

Scanning for vulnerabilities can lead to many results. How to tame the findings and get actionable?

Step one:

  • Filter all findings by the highest severity

  • Review each finding with the questions in step two

Step two, review each finding:

  • What is the potential impact
  • Can it be used by external attackers?
  • How complicated is it to be executed?
  • Is the code in use? (not easy sometimes)

Step 3:

  • Create a ticket with severity and questions/answers of the assessment
  • Include the version that is secure
  • Reduce the severity of the finding if needed.
  • Add an expectation until when this should be fixed (internal SLA)

What do you think? Let me know at andy@occamslabs.com

Andreas Tiefenthaler

Andreas likes security, enabling teams to ship secure products and coffee.