Roadmaps Security roadmaps Application, engineering and product security
Protect the code, packages, build systems and distribution channels your software depends on, from malicious packages to tampered builds.
Estimated time: 15–26 months · At about 10 hours a week.
Click a topic to see what to learn and where. Mark topics as you go; your progress is saved in this browser only.
Study the real incidents: compromised build systems, poisoned updates, hijacked packages and stolen maintainer accounts. They show where the chain breaks.
Every package brings its own dependencies, maintainers and vulnerabilities. Learn to see the full tree, not just the top level.
Typosquatting, dependency confusion and backdoored releases put malware straight into builds. Know the patterns and the registry protections.
An SBOM lists what is in your software. Learn the SPDX and CycloneDX formats, how to generate one, and what it is actually useful for.
Match your SBOM against vulnerability databases, work out whether the vulnerable code is reachable, and prioritise. Not every CVE in a dependency affects you.
Maintainer activity, release practices, security policy and popularity all signal risk. Choose dependencies the way you would choose a vendor.
Sign commits, packages and containers so consumers can verify they are unchanged and from you. Protect the signing keys or the signature means nothing.
Sigstore ties signatures to an identity and a transparency log instead of long-lived keys. Learn Cosign, Fulcio and Rekor and how to verify.
SLSA defines levels of build integrity, from scripted builds to hardened, isolated ones with verified provenance. Use it as a ladder.
Provenance records who built what, from which source, with which tools. Generate it in the pipeline and verify it before deployment.
Isolated, ephemeral, reproducible builds with pinned inputs stop an attacker tampering in the middle. Pipeline security and supply chain security meet here.
Private registries, mirrored packages, pinned versions and verified downloads cut exposure to public registry attacks. Control what can enter the build.
Generate, store and query SBOMs across all products so you can answer 'are we affected?' in minutes when the next big vulnerability lands.
VEX statements say whether a vulnerability in a component actually affects a product. They cut noise for customers and for you.
Decide what open source may be used, how it is vetted, who maintains the inventory and how you give back. An OSPO or equivalent helps.
Vendor software carries the same risks and you see even less of it. Ask for SBOMs, attestations and secure development evidence, and verify what you can.
When a package or build system is compromised, you need to know what you used, where it went and how to rotate and rebuild quickly. Plan for it.
Governments now ask vendors to attest to secure development practices. Know the frameworks and how to produce honest attestations.
Set the target SLSA levels, SBOM and signing requirements, and the roadmap to reach them across every product and team.
Executive orders, the EU Cyber Resilience Act and large customers now set supply chain expectations. Track them and turn them into engineering requirements.
Fund and contribute to the open-source projects you depend on. Their security is your security.
Modern software is mostly assembled from open-source packages, built by automated systems and distributed through registries. Each link in that chain can be attacked: a malicious package, a compromised maintainer, a tampered build or a hijacked update.
Supply chain security tracks what is in your software (SBOMs), verifies where it came from (provenance and signing), hardens how it is built (SLSA), and manages the risk of the open-source and vendor components you rely on. Major incidents have made it a priority for governments and large buyers.
Attacks through dependencies and build systems reach thousands of victims at once and are hard to detect. Regulators and customers now ask for SBOMs and attestations, so organisations need engineers who can produce them and act on them.
Take them in roughly this order. Costs and details for the ones marked with a link are on the Certifications page.
A common progression. Titles vary between companies.
All security roadmaps Back to top
Last reviewed: . Found a mistake, or want a roadmap written sooner? Contact