DevSecOps for startups on AWS: patched, scanned and written down.

For internet-facing software the gap between a fix and an attack is now hours to a day, and sometimes negative. The numbers from this year's reports say the same thing:

• Exploitation of vulnerabilities is "now the most common initial access vector for breaches. It has risen to 31%" (Verizon 2026 Data Breach Investigations Report).
• In the same report, "only 26% of the CISA KEV vulnerabilities had been fully remediated", and the median time to patch them was 43 days (Verizon DBIR 2026).
• Mandiant puts the mean time to exploit at "an estimated -7 days", meaning exploitation routinely starts before a patch exists (M-Trends 2026).
• AWS saw a PHP2Shell attempt in its honeypots on 17 October, four days before the fix shipped, and told security leaders to "measure patch and mitigation timelines in hours" for critical, internet-facing systems (AWS Security Blog).

On the day PHP2Shell shipped, a common question in the Hacker News thread was not how to fix it but when Amazon Linux 2023 would get the package. That wait is real, which is why a mitigation step and an inventory matter as much as the patch itself.

Amazon Linux 2 reached end of support on 30 June 2026 and "is no longer receiving standard security updates" (AWS). It shows: the Amazon Linux security centre lists "No Fix Planned" for PHP2Shell in AL2's core PHP package, and for the KEV-listed kernel bug CVE-2025-39964 on the AL2 core kernel. If old AMIs, old ECS nodes or a long-lived bastion still run AL2, moving them to Amazon Linux 2023 is the patch.

Teams coming from Heroku feel this gap most. The platform used to rebuild the stack under you; on AWS that job moves to whoever owns the pipeline. Our Heroku to AWS migrations set up the rebuilds as part of the move.

On AWS, most patch management for startups is not running apt upgrade on a server. It is rebuilding things from fresh inputs and rolling them out with the same pipeline you use for features. If the pipeline is good, patching is a normal deploy. If it isn't, patching is a scary event, and scary events get postponed.

Prioritise by exploitation, not by CVSS alone.

Most scanner findings will never matter: only about 1.4% of CVEs published in the first half of 2026 made it into CISA's KEV catalog (VulnCheck). So we sort findings by three questions. Is it in KEV, or is there credible exploitation? Is the affected component reachable from the internet? What does EPSS, FIRST's exploit prediction score, say about the next 30 days? CVSS breaks ties.

KEV alone is not enough either. VulnCheck measured a median of 80 days from CVE publication to KEV listing in the first half of 2026, and kernel bugs from 2018, 2022 and 2025 were added to KEV this year. A kernel fix that is "not in KEV yet" still goes out with the next AMI rotation. Most teams still sort by CVSS score alone, which is how a medium that is being exploited waits behind a dozen criticals that never will be.

What to skip at seed stage.

A SIEM, a 24/7 security operations centre, a SAST suite that files a thousand tickets on day one, and a cloud security platform licence when Security Hub's standard checks would do. Add them when a customer contract or a SOC 2 scope asks, not before. Our DevOps for startups guide maps the rest of the work by stage, and AWS for startups covers the account setup underneath it.

The best public write-ups this year, like Cloudflare's on Copy Fail, open with whether they were affected, then give a timeline, the fix and the mitigation. Ours follows five steps.

1. Triage against your inventory, within hours. SBOMs, ECR and Inspector findings, AMI IDs and the Terraform tell us where the component runs and whether it faces the internet.
2. An "are we affected" note to you. Yes, no or partly, which services, and what happens next. Short enough to forward to a customer.
3. Fix or mitigation. The patch, or a mitigation first if the distro package lags.
4. Verification. Running versions checked, a rescan, and a look through logs for signs of exploitation from before the advisory.
5. Write-up. What was affected, what we did, timestamps. Filed where your auditor and your security questionnaire answers can point to it.

"Fixed" means patched in production, or a documented mitigation in place with the patch scheduled, when no patch exists for your platform yet. Exceptions are written down with a reason and a review date, which is what an auditor asks to see.

Why write it down? SOC 2 auditors don't bring their own numbers. They read your policy, then check whether your tickets met it. A strict promise you miss is a finding; a realistic one you keep is evidence.