Vulnerability vs. Supply Chain Attack

Supply chain attacks are in all news (at least in mine). These kind of attacks happen in plain sight and use available infrastructure to do harm.

Thank you for being here. If you’ve found your way over by some miracle but are not yet subscribed, let me help you with that

Vulnerability vs. Supply Chain Attack

What is the difference between them?

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:

• 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)

• Create a ticket with severity and questions/answers of the assessment

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

LinkDump

Building a Detection-as-Code pipeline (part one, part two)

A two-part (part one, part two) in-depth walkthrough of how to build and integrate event detection from external secrets with GitHub automation by David French. Very interesting approach to combining various SaaS tools with some custom logic.

The Zero CVE Challenge: Can official Docker Hub images pass the test?

If you build your images on top of official docker hub images, are you getting security vulnerabilities with it that you could avoid? It seems that updating OS packages in popular Docker hub images reduces vulnerability counts, on average, by only 5.5%. It might be better to build your own images sometimes

GitHub Actions Goat

A deliberately Vulnerable GitHub Actions CI/CD Environment. This is a good resource to make yourself familiar with some of the biggest problems in CI/CD pipelines and how to spot them.

Thank you

Thank you for reading along. If you have feedback or questions, message me: andy@occamslabs.com. I would appreciate it if you shared it with people that can benefit from the newsletter.