Keshav Malik

Software supply chain security engineering

Most software is built on code and systems we do not own. Every package, GitHub Action, build runner, and release token is something we choose to trust. I trace that trust from the first dependency to the final release, then add checks where one bad package or stolen credential could do real damage.

01 / Approach

How I approach supply chain security.

  1. Know what enters the build

    I start with the packages and tools a build pulls in. I check where they came from, who published them, and what changed in the lockfile. A familiar package name is not enough on its own.

  2. Follow the release path

    Next, I follow the code through CI and into the package registry. I look for places where a workflow can change, a secret can leak, or an artifact can be replaced before it is published.

  3. Put checks in the build

    I prefer a small check that runs on every build over a policy that people have to remember. When a check fails, it should say what happened and how the developer can fix it.

02 / Evidence

Things I have built and changed.

03 / Questions

Questions about supply chain security.

01

What does a software supply chain security engineer do?

A software supply chain security engineer protects the path from source code to a published release. They check which dependencies enter a build, who can change the build, what access each job has, and who can publish the result. Their work stops an untrusted change from looking like an official release.

NIST Secure Software Development Framework
02

How is software supply chain security different from SCA?

Software composition analysis, or SCA, tells you which third-party packages you use and whether they have known problems. Supply chain security also looks at how packages enter the build, what runs in CI, who can publish, and whether someone changed an artifact. SCA is one part of that work.

SLSA supply chain framework
03

What should a team secure first in its software supply chain?

Start with the workflow that publishes your software. Find out who can change it, what outside code it runs, which secrets it can use, and where it sends the final artifact. Remove access it does not need, pin outside actions to fixed versions, and protect the release job.

GitHub Actions secure use reference
04

What does software provenance prove?

Software provenance is a record of how an artifact was built. It can show which source, build system, and inputs produced a release. That helps someone check where the release came from, but it does not mean the code has no security bugs.

SLSA build provenance specification

04 / Related

02CI/CD security ↗03Application security ↗04Static analysis ↗

05 / Contact

Working on a problem like this?

hello@theinfosecguy.xyzLinkedIn