Most of the code running in your web app wasn't written by your team. It came from open-source packages, which bring their own dependencies. Software supply chain security means making sure none of that borrowed code, or the pipeline that builds and ships it, becomes the way in for an attacker. You don't need a security team to get the basics right.
Why it matters now
Attackers have learned it's easier to compromise one popular package, or one developer's publishing account, than thousands of individual apps. A single malicious update can reach every project that installs it. AI coding tools add a new risk: they sometimes suggest packages that don't exist, and attackers register those names.
A practical checklist
Dependencies
- Commit your lockfile (
package-lock.json,pnpm-lock.yaml) and install withnpm ciin CI, so builds use exactly the versions you tested. - Run
npm audit(or an equivalent) in CI and fix high-severity issues promptly. - Remove packages you no longer use. Every dependency is attack surface.
- Check new packages before adding them: maintainers, download history, and whether the name is a lookalike.
Build and deploy
- Keep secrets out of the repository. Use your host's or CI's secret store.
- Give CI tokens the minimum permissions they need.
- Pin third-party CI actions to a specific version or commit, not a moving tag.
- Turn on two-factor authentication everywhere, especially on npm and GitHub.
Visibility
- Generate an SBOM (software bill of materials) for production builds, so you can answer "are we affected?" quickly when the next vulnerability hits.
- Turn on automated dependency update pull requests, and actually review them.
Frameworks like SLSA describe how to mature this further. The list above covers most of the risk for a typical small team.
Security as a default
At NextGen Fusion, our web and software development company in Lucknow, every project ships with lockfiles, CI checks and secrets handled properly, as the default rather than an add-on.
