SOFTWARE SUPPLY CHAIN SECURITY
Software supply chain security: what can go wrong, and what to check
Most of the code you ship was written by someone else, and it reaches production through a CI pipeline with access to your secrets. Software supply chain security is about protecting that path: the packages you depend on, the build that turns code into artifacts and the credentials along the way. This guide covers the main threats, the SLSA and SBOM frameworks and exactly which parts Nurbak checks.
Create account and connect GitHubWe never store your code. We only write when you ask for a fix PR.
Dependencies are your code too
A known CVE in a package you import is as exploitable as a bug you wrote. Keeping track of which versions are affected is the baseline.
CI is part of the supply chain
A workflow that runs untrusted code with write access or secrets can let an outsider change what you ship.
Secrets are the keys
Tokens in code, in old commits or baked into Docker images let attackers publish, deploy or read data in your name.
Clear about scope
Nurbak checks your repo for these risks. It does not generate SBOMs, sign artifacts or detect malicious packages beyond known advisories.
The main software supply chain threats
Vulnerable dependencies
Direct and transitive packages with published CVEs. The fix is usually a version bump, if you know which version fixes it. Software composition analysis.
Malicious packages and typosquatting
Packages published to look like popular ones, or legitimate packages taken over and updated with malicious code. Registries remove many of them, but new ones keep appearing.
pull_request_target in GitHub Actions
GitHub warns these workflows are privileged and may have write access and secrets, so they must not check out untrusted code from pull request forks.
Script injection in workflows
Putting values like a pull request title straight into a run script lets an attacker inject commands. GitHub recommends passing them through an environment variable.
Unpinned third-party actions
A tag like @v3 can be moved. GitHub says pinning an action to a full-length commit SHA is currently the only way to use it as an immutable release.
Leaked secrets
API keys and tokens in source files, in the git history or in Dockerfiles. Deleting the line doesn't remove it from old commits. Secret scanner.
Frameworks: SLSA and SBOM
SLSA
Supply-chain Levels for Software Artifacts is a security framework, a checklist of standards and controls to prevent tampering, improve integrity and secure packages and infrastructure (slsa.dev).
SLSA build levels
In SLSA v1.0, Build L1 means provenance showing how the package was built, L2 adds signed provenance generated by a hosted build platform, and L3 requires a hardened build platform.
SBOM
CISA describes a software bill of materials as a nested inventory, a list of ingredients that make up software components. Nurbak does not generate SBOMs. What is an SBOM.
Supply chain threats and what Nurbak checks
Each threat, a common control and whether Nurbak covers it. Where Nurbak doesn't, we say so.
| Threat | Common control | What Nurbak does |
|---|---|---|
| Vulnerable dependencies | SCA on every change, lockfiles, prompt upgrades | Finds dependency CVEs via OSV and tells you the fixed version |
| Malicious packages, typosquatting | Review new dependencies, lockfiles, registry advisories | Only flags packages with known advisories in OSV. No detection of new malicious packages |
| pull_request_target misuse | Never check out untrusted code in privileged workflows | Checks GitHub Actions workflows for risky pull_request_target use |
| Script injection in workflows | Pass untrusted input through environment variables | Checks GitHub Actions workflows for injection |
| Unpinned actions | Pin third-party actions to a full commit SHA | Not among the checks listed here. Follow GitHub's guidance |
| Leaked secrets | Secret scanning, including history, and rotation | Finds secrets in code, in git history and in Dockerfiles |
| Build tampering | SLSA provenance, artifact signing | No. Nurbak does not sign artifacts or generate provenance |
| Unknown inventory | Generate and share an SBOM | No. Nurbak does not generate SBOMs |
How Nurbak checks your repo's supply chain
Create an account and connect GitHub. Public and private repos both work.
Pick a repo. Nurbak's own model analyzes it on ephemeral infrastructure.
Get dependency CVEs with the fixed version, GitHub Actions and Dockerfile issues and secrets in git history, in a 0 to 100 security score.
Open a pull request with the fix and a security regression test in one click.
On a plan, the repo is rescanned daily, so newly published CVEs are caught too.
Software supply chain security FAQ
What is software supply chain security?
It is the practice of protecting everything that goes into your software and the path it takes to production: open source dependencies, build and CI systems, the credentials they use and the artifacts they publish. An attacker who compromises any of those can reach your users without touching your own code.
What are software supply chain security tools?
They include SCA tools that match dependencies against vulnerability databases, secret scanners, CI and IaC configuration scanners, SBOM generators, and signing and provenance tools for builds. Nurbak covers the first three for your GitHub repo: dependency CVEs via OSV, secrets including git history and GitHub Actions, Docker, Terraform and Kubernetes checks.
How do I improve npm supply chain security?
Commit your lockfile, review new dependencies before adding them, keep versions current and check them against known vulnerabilities. npm's own npm audit command submits a description of your dependencies to your default registry and asks for a report of known vulnerabilities. Nurbak also checks npm dependencies against OSV and shows the fixed version.
Does Nurbak detect malicious packages?
Only when a package has a known advisory in the OSV database. Nurbak does not analyze package behavior to detect new malicious or typosquatted packages, so pair it with registry advisories and careful review of new dependencies.
Does Nurbak generate an SBOM or sign artifacts?
No. Nurbak does not generate SBOMs, does not sign artifacts and does not produce SLSA provenance. It finds vulnerable dependencies, secrets and CI misconfigurations in your repo. Our guide what is an SBOM explains how SBOMs work.
Which GitHub Actions risks does Nurbak check?
Nurbak reviews your workflows for script injection from untrusted input and risky use of pull_request_target, along with other misconfigurations in GitHub Actions, Dockerfiles, Terraform and Kubernetes. See GitHub security scanner and our guide to secret scanning tools.
How much does it cost?
The first scan is free and shows the 3 most important findings in full, plus 1 free fix PR. Plans are USD 79 per month for 1 repo and USD 199 per month for up to 5 repos, with daily scans. Above 5 repos there is an Enterprise plan. We charge per repo, not per developer. See pricing.
Check your repo's supply chain today
Connect GitHub and get your security score and your 3 most important findings free.
Scan my repo