A notification lands in your inbox at 7 a.m. A popular open-source library your product depends on has been pulled from its registry. Or worse — a maintainer account was hijacked and a malicious version was pushed overnight. Your stomach drops. You have no dedicated Security Operations Centre, a small engineering team, and customers who expect you to have answers by lunchtime.
This is not a hypothetical. Supply-chain attacks have become an increasingly preferred entry point for adversaries targeting organisations that cannot defend every perimeter simultaneously — a trend documented by the European Union Agency for Cybersecurity (ENISA). For SMEs and SaaS teams, the Software Bill of Materials — your SBOM — is both your early-warning system and your first line of evidence. If you do not know what is in it, or whether it has been tampered with, you are flying blind.
This playbook walks you through the first 24 hours, hour by hour, using tooling that is either free or low-cost, so you can move from panic to structured response before you spend a single pound on external help.
Recognizing the Warning Signs: How SBOM Compromise Surfaces in the First Hour
Before you can respond, you need to recognise what an SBOM compromise actually looks like on the ground. It rarely announces itself cleanly.
Common trigger signals in the first hour:
- Public disclosure alerts. A CVE is published, a GitHub security advisory lands, or a package registry (npm, PyPI, Maven Central, RubyGems) issues a tamper or typosquatting notice. Subscribe to the GitHub Advisory Database and OSV (Open Source Vulnerabilities) RSS feeds so these reach you automatically.
- Unexpected build failures or checksum mismatches. Your CI/CD pipeline throws errors on a dependency it successfully resolved yesterday. Lock-file hashes no longer match. This is a red flag, not just a nuisance.
- Unusual runtime behaviour. An application starts making outbound connections to unfamiliar IP addresses, performance degrades without a code change, or log volumes spike. These can indicate a compromised dependency that has already been deployed.
- Third-party intelligence. A customer reports anomalous API calls. A threat intelligence feed you subscribe to — even a free one like CISA's Known Exploited Vulnerabilities (KEV) catalogue — flags a component in your stack.
- Dependency and Supply-Chain Watch alerts from your tooling. If you have already configured automated dependency monitoring, an alert fired overnight may be sitting in a queue waiting for a human to act on it.
What to do in the first 60 minutes:
- Do not dismiss it as a false alarm until you have checked. Assign one person as incident lead — even if that person is you.
- Screenshot and timestamp every alert, email, and log entry you see. Evidence degrades quickly once systems restart or log rotation kicks in.
- Pull your current SBOM. If you generate SBOMs at build time (using a tool like Syft, cdxgen, or Trivy), locate the most recent artefact. If you do not yet generate SBOMs automatically, note that gap — you will address it in the post-incident review.
- Cross-reference the flagged component against your SBOM. Is it present? In which services? At what version?
The goal of hour one is not to fix anything. It is to confirm that the threat is real and to preserve the state of your environment before any well-meaning engineer runs npm update and destroys your forensic baseline.
Hours 1–4: Free and Low-Cost Tools to Verify Your Dependency and Supply-Chain Watch
Once you have confirmed the signal is worth investigating, your next priority is rapid verification using tools that do not require a procurement process or a six-figure contract.
SBOM generation and diffing
If you do not have a current SBOM, generate one immediately:
- Syft (free, open-source): Run
syft <image or directory>to produce a CycloneDX or SPDX-format SBOM in minutes. - Trivy (free, open-source):
trivy sbom <image>generates an SBOM and simultaneously scans for known vulnerabilities. One command, two outputs. - cdxgen (free, open-source): Particularly strong for polyglot repositories and container images.
Once you have an SBOM, compare it against your last known-good version. A simple diff of two CycloneDX JSON files will surface added, removed, or version-changed components. Even a git diff on your lock files (package-lock.json, Pipfile.lock, go.sum) will reveal unexpected changes.
Vulnerability and integrity checking
- OSV-Scanner (free, Google): Scans your dependency manifest or SBOM against the OSV database, which aggregates advisories from GitHub, PyPI, RubyGems, and more. Run
osv-scanner --sbom <your-sbom.json>. - Grype (free, Anchore): Fast vulnerability scanner that accepts SBOMs directly. Pair with Syft for a tight generate-then-scan workflow.
- CISA KEV catalogue (free): Manually cross-reference affected packages against CISA's Known Exploited Vulnerabilities list. Any match elevates priority immediately.
- Socket.dev (freemium): Analyses npm and PyPI packages for supply-chain-specific risks — malware, dependency confusion, typosquatting, and maintainer account anomalies — not just CVEs. The free tier covers basic scanning.
- deps.dev (free, Google): Provides dependency graphs, version histories, and known vulnerability data. Useful for understanding the blast radius of a transitive dependency.
Registry integrity checks
For npm packages, run npm audit and check the package's published hash against the registry. For Python, use pip-audit. For Java, compare artifact checksums against Maven Central's published SHA-1/SHA-256 values.
If the hash of a package you have cached locally does not match what the registry now serves — or what your lock file recorded — treat it as a suspected compromise and investigate further before drawing conclusions.
Log triage
Pull your application logs for the past 72 hours. Search for:
- DNS queries to domains not in your known-good allow list
- Outbound connections initiated by your application process
- Unusual file-write activity in dependency directories
Tools like Loki (free, Grafana) or even a simple grep pipeline across exported logs can surface these patterns without a SIEM.
By the end of hour four, you should have a definitive list of affected components, their versions, where they are deployed, and whether any are confirmed as malicious or merely vulnerable.
Hours 4–8: Isolating Affected Components and Assessing Blast Radius
Verification is complete. Now you need to contain the damage — but carefully, because hasty changes can destroy evidence and introduce new instability.
Immediate containment actions
- Pin and freeze. Lock your package manager to the last known-good version of the affected dependency. Commit the lock file change to a branch — do not merge yet. This prevents any automated dependency update pipeline from pulling the malicious version into other environments.
- Block at the network layer. If runtime analysis shows outbound connections to suspicious endpoints, add a firewall rule or modify your egress security group to block those IPs or domains. This is a temporary measure that buys time without requiring a full rollback.
- Pause automated deployments. If you use a CI/CD pipeline with automatic deployments (GitHub Actions, GitLab CI, Buildkite), disable the deployment step or add a manual approval gate. You do not want a triggered build pushing compromised code to production while you are still triaging.
Blast radius assessment
This is where your SBOM earns its keep. Work through the following questions systematically:
- Which services consume the affected component? If your SBOM covers all services, a simple search for the package name will return every affected repository and container image.
- Is the component a direct or transitive dependency? Transitive dependencies are harder to swap out but can sometimes be overridden via dependency resolution configuration.
- What data does the affected service handle? A compromised component in a service that processes payment card data or personal health information carries a fundamentally different regulatory weight than one in an internal analytics tool.
- Has the component been deployed to production? Check your deployment logs. If the malicious version never made it past staging, your blast radius is dramatically smaller.
- What permissions does the affected service have? A service with broad IAM permissions, database write access, or access to secrets management represents a higher risk than a read-only reporting service.
Document your blast radius findings in a simple table: service name, dependency version deployed, data classification, external exposure (yes/no), and current status (clean / suspect / confirmed compromised). This document will drive every subsequent decision.
Rollback decisions
If a confirmed malicious version is running in production, initiate a rollback to the last known-good container image or deployment. Most cloud platforms (AWS ECS, GCP Cloud Run, Azure Container Apps, Heroku) support one-command rollbacks. Do this before the end of hour eight if at all possible. Pair the rollback with a secrets rotation for any credentials the affected service had access to — assume they are burned.
Hours 8–16: Communicating Internally and Preserving Evidence Without a SOC
Without a dedicated SOC, the burden of communication and evidence preservation falls on whoever is running the incident. Structure matters here. Ad-hoc Slack messages and verbal updates create gaps that will hurt you later — in a post-mortem, in a regulatory inquiry, or in a conversation with cyber insurance.
Internal communication
Set up a dedicated incident channel (Slack, Teams, or even a shared email thread) and establish a simple cadence: status updates every two hours, even if the update is "no change." This prevents leadership and colleagues from interrupting the technical responders with "what's happening?" messages.
Your updates should cover:
- Current confirmed scope (what is affected)
- Current containment status (what has been done)
- Next actions (what is happening in the next two hours)
- Open questions (what you still do not know)
Keep a running incident log — a shared Google Doc or Notion page works fine. Every action taken, every finding made, every decision and its rationale should be timestamped and recorded. This is your audit trail.
Customer and stakeholder communication
If personal data may have been accessed, your legal obligations under GDPR (72-hour notification window to the supervisory authority), HIPAA, or applicable state privacy laws begin running from the moment you have reasonable grounds to believe a breach occurred — not from when it is confirmed. Consult your legal counsel or DPO early. Do not wait for certainty.
For SaaS businesses, a brief holding statement on your status page ("We are investigating a potential issue with a third-party component and will provide an update by [time]") is almost always better than silence. Customers who find out through a news article rather than from you will not forgive it.
Evidence preservation
Without a SIEM or forensic tooling, you need to be deliberate:
- Export and archive current application logs before log rotation occurs. Most cloud logging services (CloudWatch, GCP Logging, Azure Monitor) allow log export to cold storage with a few clicks.
- Capture container images at their current state using
docker commitor by tagging and pushing the running image to a private registry before any rollback. - Preserve your current lock files and SBOM artefacts in version control or a time-stamped archive. These prove what was deployed at what time.
- Take screenshots of any public advisories, registry notices, or threat intelligence reports that triggered the incident. Web pages change or disappear.
Hours 16–24: Deciding When to Escalate and How to Choose a Specialist
By this point you have contained the immediate threat (or confirmed it was limited in scope), communicated with stakeholders, and built an evidence archive. Now you need to make a clear-eyed decision: handle this internally with what you have, or bring in external expertise?
Escalate immediately if any of the following apply:
- Confirmed data exfiltration. If logs show data leaving your environment to an external endpoint, you need a digital forensics and incident response (DFIR) specialist, a lawyer, and potentially your cyber insurer on the phone today.
- Regulatory notification triggers. If personal data of EU residents, US healthcare data, or payment card data may have been compromised, legal and regulatory obligations require expert guidance to navigate correctly.
- Persistence indicators. If you find evidence that an attacker established persistence — a new user account, a modified binary, a cron job you did not create — the scope of the incident has grown beyond a dependency swap and requires forensic investigation.
- You cannot verify clean state. If you cannot confidently assert that your production environment is running known-good code after your containment actions, you need help.
- Cyber insurance requirement. Many cyber insurance policies require you to notify the insurer and use their approved incident response panel. Check your policy now.
How to choose a specialist quickly
Time matters. When evaluating firms in an emergency:
- Prioritise supply-chain and software security expertise. General IT security firms may lack the specific knowledge needed to forensically analyse a compromised dependency chain. Ask directly: "Have you handled software supply-chain incidents? Can you reference recent engagements?"
- Check for CREST or equivalent accreditation. In the UK, CREST-accredited firms meet a defined quality standard for incident response. In the US, look for firms with SANS-certified responders (GCFE, GCIH, GCFA).
- Understand retainer versus ad-hoc pricing. An emergency call-out without a pre-existing retainer will be expensive. Use this incident as the trigger to put a retainer in place afterwards.
- Ask about SME experience. Some specialist firms primarily serve enterprise clients and will overwhelm a 50-person SaaS company with process overhead. You want a firm that can work at your scale and pace.
- Involve your cyber insurer. If you have a policy, call the claims line now. They have pre-approved panels, can cover costs, and have an interest in seeing the incident resolved correctly.
If the incident appears contained and limited in scope — a vulnerable but not yet exploited component, no evidence of exfiltration, blast radius limited to non-sensitive data — you may be able to proceed internally. Document your rationale for that decision explicitly.
Building a Lightweight Post-Incident SBOM Review Process for SMEs
The 24-hour sprint is over. Whether you escalated or handled it in-house, the most valuable thing you can do now is prevent the next incident from being this stressful.
Automate SBOM generation in your pipeline
Every container image and deployable artefact should have an SBOM generated at build time and stored alongside it. Integrate Syft or Trivy into your GitHub Actions or GitLab CI workflow. This takes less than a day to implement and means you will never again scramble to figure out what is deployed.
# Example GitHub Actions step using Syft
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
image: your-registry/your-image:${{ github.sha }}
format: cyclonedx-json
output-file: sbom.cyclonedx.jsonImplement continuous Dependency and Supply-Chain Watch
Punctual scanning is not enough. Vulnerabilities are disclosed continuously, and a dependency that was clean at build time can become dangerous 48 hours later. Configure:
- GitHub Dependabot (free) for automated pull requests when new vulnerabilities are published against your dependencies.
- OSV-Scanner in CI to fail builds when new high-severity vulnerabilities appear in your dependency graph.
- Socket.dev or a commercial equivalent for supply-chain-specific signals — malware injection, maintainer account anomalies, and dependency confusion attacks that CVE databases do not catch.
Dependency and Supply-Chain Watch should be a continuous background process, not a quarterly checkbox.
Establish a minimal incident runbook
Document the steps from this playbook in a one-page runbook specific to your environment: where your SBOMs are stored, who the incident lead is, which communication channels to use, and which regulatory obligations apply to your data. Keep it somewhere everyone can find it at 7 a.m. on a Monday.
Schedule a quarterly SBOM review
Once a quarter, pull SBOMs for your three most critical services and review them manually. Look for:
- Dependencies that have not been updated in over 12 months (higher risk of abandonment or takeover)
- Dependencies with very few maintainers (single points of failure)
- Transitive dependencies you have never consciously chosen to include
This review does not need to take more than two hours and will surface risks that automated tooling misses.
Build relationships before you need them
If this incident revealed that you would benefit from external expertise, engage a specialist firm now — not during the next crisis. A lightweight retainer arrangement gives you access to expertise on demand, ensures you are a priority client when incidents occur, and is almost always cheaper than emergency call-out rates.
A supply-chain breach is disorienting precisely because the attack surface is not something you built — it is something you trusted. The SBOM turns that trust into an auditable record, and this playbook turns that record into a structured response. You do not need a 20-person SOC to get through the first 24 hours. You need a clear process, the right free tools, and the discipline to document as you go.
The teams that weather these incidents best are not the ones with the biggest security budgets. They are the ones who prepared when it was quiet.