Secure by Design & Threat Intelligence

This page is really two questions that turn out to be the same question asked from opposite ends of a supply chain. First: when a vendor signs CISA's Secure by Design pledge, what have they actually promised — and what does that promise not cover? We'll go past the press-release version and into the seven specific commitment areas, why memory-safe languages and eliminated default passwords are treated as flagship goals, and where the pledge quietly stops short of a guarantee. Second, and this is the half a platform team lives in every single week: once a CVE exists — whether or not the vendor who shipped the flaw did everything right — how do you decide, out of the hundreds sitting in your backlog, which one to fix today? A CVSS score alone can't answer that. This page builds the pipeline that can, out of CVE feeds, the CISA KEV catalog, EPSS, and ISAC intelligence.

The CISA Secure by Design pledge: what a vendor actually signs

☺ Like you're 10: Signing this pledge isn't a certificate saying "this company is secure now." It's a public, named promise to work toward seven specific, checkable goals over the next year.

In April 2023, CISA, the NSA, the FBI, and cybersecurity agencies from the UK, Australia, Canada, New Zealand, Germany, and several other countries co-published a white paper called Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design and Secure by Default. Its argument was blunt: for decades, the software industry has shipped products with easily preventable vulnerabilities and treated the resulting breaches as the customer's operational problem rather than the vendor's design failure. The paper set out three principles a vendor should hold — take ownership of customer security outcomes, embrace radical transparency and accountability, and build the internal organizational structure and leadership to actually pursue both — and it drew a line between two words people tend to use interchangeably:

• Secure by design — the product is architected from the start to structurally reduce entire classes of vulnerability. This is expensive to retrofit: choosing a memory-safe language, threat modeling a feature before it's built, designing an API so the insecure usage is the awkward one. You can't bolt this on after shipping; it's a decision baked into the architecture.
• Secure by default — the product ships safe out of the box, with no extra configuration and no extra cost required to get there. MFA enabled without the customer hunting for a settings page, no default admin password to change, full audit logging included at every pricing tier instead of gated behind the enterprise SKU.

A year later, at the RSA Conference in May 2024, CISA turned those principles into something concrete: the Secure by Design Pledge, a voluntary, publicly-signed commitment structured around seven specific goal areas, each with a one-year horizon for "measurable progress" — not instant compliance, and not a certification. Sixty-eight companies signed at launch, including Microsoft, Google, AWS, Cisco, IBM, Okta, GitHub, Fortinet, and CrowdStrike; the roster has grown well past that since — check CISA's own signatory list for the current count and who's actually on it, since both change continuously.

Two of these — patches and evidence of intrusions — exist because of specific, named incidents. The evidence-of-intrusions goal traces directly to the 2023 Storm-0558 breach, which we'll come back to in the next section. The whole pledge, in other words, isn't abstract principle; every line item maps to a real failure that CISA watched happen.

Eliminating whole vulnerability classes: the memory-safe language commitment

☺ Like you're 10: A memory-safety bug is like a filing cabinet that lets you write past the edge of a drawer into the drawer next to it. Some programming languages simply don't let you do that, ever, no matter how tired the programmer was that day.

Of the seven goals, "reduce entire classes of vulnerability" is the one CISA and the NSA have pushed hardest, and memory safety is the reason why. In December 2023, CISA and the NSA jointly published The Case for Memory Safe Roadmaps, building on an NSA information sheet from a year earlier that named the languages it considers memory-safe: Rust, Go, C#, Java, Swift, and Python among them, contrasted against C and C++, where the language itself does nothing to stop a buffer overflow, a use-after-free, or a double-free — it trusts the programmer to get pointer arithmetic right, every time, forever. Microsoft's own vulnerability data, presented publicly by its security team as far back as 2019, found that roughly 70% of the CVEs it assigned each year traced back to a memory-safety root cause. Google reported a near-identical figure for Chromium. That's not "a bug category worth watching" — it's the single largest source of exploitable vulnerabilities in software written in unsafe languages, consistently, across completely unrelated codebases.

"Publish a memory-safe roadmap" as a pledge commitment doesn't mean rewriting an existing C++ codebase overnight — nobody is asking for that, and it isn't realistic. It means a public, dated commitment to write new code in a memory-safe language going forward, with measurable targets, and it's already showing up as real, published results rather than just intent:

• Android — Google has published data showing that as new Android code shifted to Rust, the share of the platform's vulnerabilities attributable to memory safety fell sharply year over year, even as the total volume of new code grew — direct evidence that the fix generalizes rather than just moving the bug somewhere else.
• AWS — Firecracker (the microVM behind Lambda and Fargate) and Bottlerocket (AWS's container-optimized Linux distribution) are both written in Rust from the ground up, not retrofitted.
• Microsoft — has been incrementally rewriting memory-safety-sensitive components of the Windows kernel and font-rendering stack in Rust, on the reasoning that font parsing and kernel code are exactly the attack surface where a single memory bug is catastrophic.

This is the design half of the pledge, and it's exactly why it can't be retrofitted the way a default password can be flipped off in a config file: choosing Rust over C for a new service is an architecture decision made once, at the start, that structurally forecloses an entire bug class for the life of that code. See Secure Coding Patterns for what this looks like at the level of an individual function and code review, rather than a company-wide roadmap.

Secure defaults: no default passwords, MFA that's on by default

☺ Like you're 10: A lock the factory ships already set to "1-2-3-4" isn't really a lock — it's a lock-shaped promise that someone will remember to change the code before it matters. Most people don't.

Default credentials are the oldest, dumbest, and still most-exploited class of vulnerability in the industry, which is exactly why the pledge names it explicitly rather than folding it into the general "reduce vulnerability classes" goal. The Mirai botnet that knocked large parts of the internet offline in 2016 spread almost entirely by scanning for IoT devices still running their factory-set username and password. Nearly a decade later, CISA's own advisories tying the China-linked Volt Typhoon actor to pre-positioning inside U.S. critical infrastructure repeatedly flagged the same root cause in routers and OT/ICS equipment: a default credential nobody had ever been forced to change. The pledge's default-password commitment specifically targets this — not "recommend a password change," but eliminate the default entirely, forcing a unique password at first boot before the device does anything else.

MFA gets the same treatment for a related reason. CISA's language around this goal is pointed: MFA should be default-on, and specifically phishing-resistant MFA — hardware security keys and platform passkeys using FIDO2/WebAuthn — rather than SMS one-time codes, which remain vulnerable to SIM-swapping and real-time phishing proxies. The pledge also calls out, without naming names, vendors who gate MFA or full audit logging behind a premium pricing tier — security as an upsell rather than a baseline.

That last point isn't hypothetical. In the summer of 2023, a China-linked actor CISA's own Cyber Safety Review Board later tracked as Storm-0558 forged authentication tokens using a stolen Microsoft signing key and read email out of several U.S. government Exchange Online mailboxes, including the State Department's. The CSRB's report found that the victim who caught it — the State Department — did so because it was licensed for the Microsoft 365 tier that included the diagnostic logging that surfaced the anomaly; customers on lower tiers had no equivalent visibility and would have had no way to detect the same intrusion. Microsoft responded by expanding that logging to every customer at no extra cost. That single incident is the concrete, named reason the pledge's "evidence of intrusions" goal exists at all — see Detection Engineering & Security Observability for what an organization actually does with that logging once it's available.

From vendor pledge to platform practice

☺ Like you're 10: Everything the pledge asks a software vendor to promise its customers, your platform team is also quietly promising every developer who builds on top of it.

It's tempting to read the pledge as a document about other companies — Microsoft, Cisco, the vendors whose products you consume. But the same three principles apply one layer down, inside your own organization, because your platform team is a vendor too: the internal developers building services on top of your golden paths are its customers. "Take ownership of customer security outcomes" is exactly the argument for building security guardrails into the platform itself rather than publishing a wiki page of best practices and hoping every team reads it. A scaffolded service that starts with a hardcoded default database password, no MFA on its deploy pipeline, and logging that's easy to skip is bolted-on security wearing an internal badge — the exact pattern the pledge exists to push vendors away from, just moved inside the firewall.

Concretely, that means threat modeling a new platform capability during design rather than auditing it after launch (see threat modeling and Secure SDLC Gates & the DevSecOps Maturity Model), an internal equivalent of a vulnerability disclosure policy so an engineer who finds a platform-level gap has a clear, blameless path to report it, and CVE-completeness discipline applied to your own internal advisories — when your platform team ships a security bulletin for an internal library, does it name the actual root cause, or just "a security issue was fixed"? Maturity frameworks like DSOMM, SAMM & BSIMM exist precisely to turn "we try to do this" into something you can actually measure year over year, the same way the pledge asks external vendors to measure their own progress.

Consuming external threat intelligence: CVE, NVD, the KEV catalog & EPSS

☺ Like you're 10: A CVE number is just a name for a problem. It doesn't tell you how bad it is, whether anyone's actually using it to break in, or whether it's you they're breaking into.

Every publicly tracked vulnerability starts as a CVE (Common Vulnerabilities and Exposures) record, assigned an ID by a CNA — a CVE Numbering Authority, usually the vendor itself or MITRE, which runs the overall program. On its own, a bare CVE record is close to useless for prioritization: an ID and a one-line description, nothing about severity, nothing about what's affected in machine-readable form. Software Composition Analysis in Depth already covers how to read the CVSS vector that's supposed to fill that gap; this page picks up where that one leaves off, at the question of where the enrichment data actually comes from and what to do when it's missing, late, or simply not the whole story.

Historically that enrichment came from the NVD — the National Vulnerability Database, run by NIST — which assigns the CVSS score and the CPE (Common Platform Enumeration) data describing exactly which products and versions are affected. In February 2024, NVD dramatically slowed its own analysis, and a large backlog of unenriched CVE records built up — records with an ID and a description, but no CVSS score, no CPE, nothing a vulnerability scanner could automatically match against your inventory. CISA responded a few months later by launching Vulnrichment, publishing its own CVSS, CWE, and CPE enrichment for a subset of CVEs to help close the gap. Check both NVD's and CISA's own status pages for where the backlog stands today — this situation has kept evolving, and the specific numbers age fast.

Two other feeds matter more than CVSS for the question this page actually cares about — what to fix first:

The KEV catalog exists because of Binding Operational Directive 22-01, which requires U.S. federal civilian agencies to remediate any vulnerability added to the catalog within a set window — commonly two weeks for newly added, urgent entries, longer for some older ones CISA back-filled at launch. That directive is legally binding only for federal agencies, but its logic is sound for anyone: an entry in KEV means CISA has confirmed, real-world evidence of exploitation, which is a categorically stronger signal than a CVSS score, and a large share of private organizations now apply the same "if it's in KEV, patch within two weeks regardless of severity label" rule voluntarily. Vulnerability Management & Triage covers exactly this as an SLA-escalation trigger sitting on top of a severity table — this page is about the feed that trigger reads from.

# Pull the live KEV catalog and check it against packages named in your own SBOM inventory
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  -o kev.json

jq -r '.vulnerabilities[] | select(.dateAdded >= "2026-08-01") |
  "\(.cveID)  \(.vendorProject) \(.product)  due \(.dueDate)"' kev.json

# Cross-reference one CVE ID against every SBOM your platform team has on file
grep -l "CVE-2024-XXXXX" sboms/*.cdx.json

# Pull today's EPSS score and percentile for the same CVE from FIRST.org's API
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2024-XXXXX" | jq '.data[0]'

ISACs and structured sharing: STIX, TAXII & sector intelligence

☺ Like you're 10: A general weather report tells everyone it might rain somewhere. Your neighbor calling to say "it's hailing on our street right now" is a completely different kind of useful.

CVE feeds, KEV, and EPSS are all sector-agnostic — they treat a vulnerability in a payments API the same as one in a hospital's patient portal. ISACs — Information Sharing and Analysis Centers — exist to add the context those feeds can't: intelligence specific to what's actually being used against organizations in your exact industry, right now, often before it's public. Membership is organized under the National Council of ISACs, and coverage is sector-specific: FS-ISAC for financial services, H-ISAC for healthcare, Auto-ISAC for automotive, E-ISAC for electricity (run by NERC), IT-ISAC for the technology sector, and MS-ISAC — run by the Center for Internet Security, and free to join — for U.S. state, local, tribal, and territorial governments specifically. A phishing campaign or a specific malware sample hitting one regional bank tends to get reused, with minor variation, against the next one; FS-ISAC members hear about it from a peer institution, often within hours, well before it would show up as a public CVE or make the news.

Most ISACs exchange this intelligence in a structured, machine-readable format so it can be ingested automatically rather than read as a PDF bulletin: STIX (Structured Threat Information Expression) 2.1 defines a common vocabulary of objects — Indicator, Malware, ThreatActor, Campaign, Relationship — and TAXII (Trusted Automated Exchange of Intelligence Information) 2.1 is the REST-based transport that moves STIX content between a producer's server and a consumer's, organized into subscribable "collections." Some ISACs and many members instead run MISP (Malware Information Sharing Platform), an open-source alternative that predates broad STIX/TAXII 2.x adoption and remains widely deployed alongside it. A minimal STIX indicator, the kind an ISAC feed might push the moment a member confirms a malicious IP is actively scanning for a specific CVE, looks like this:

{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--8e2e2d02-9a5f-4f1c-8d1a-example",
  "created": "2026-08-14T09:12:00Z",
  "pattern": "[ipv4-addr:value = '203.0.113.44'] AND [network-traffic:dst_port = 443]",
  "pattern_type": "stix",
  "valid_from": "2026-08-14T09:12:00Z",
  "indicator_types": ["malicious-activity"],
  "description": "Source actively scanning FS-ISAC member networks for CVE-2024-XXXXX; reported by three member institutions in the last 6 hours."
}

ISAC access, unlike KEV or EPSS, is neither universal nor free — most require sector membership and dues, MS-ISAC being the notable public-sector exception. Treat it as the highest-context, narrowest-coverage layer of threat intelligence: valuable specifically because it tells you what's aimed at organizations like yours, not a replacement for the broad public feeds that cover everyone else's vulnerabilities too.

Beyond a single CVSS number: building a real patch-priority signal

☺ Like you're 10: Knowing how bad a fire would be if it started isn't the same as knowing there's smoke in the building right now. You want both answers before you decide which exit to run to first.

Here's the mistake this whole page has been building toward correcting: reading a CVSS score off a scanner report and treating that number, alone, as your priority order. Vulnerability Management & Triage already named this "severity is not priority" as its single most common mistake — a Critical CVSS score sitting in code your application never actually calls is a lower real-world priority than a Medium sitting on a reachable, internet-facing endpoint that's actively being exploited today. This page's version of that same lesson has a name attached: Equifax. The vulnerability was CVE-2017-5638, an Apache Struts2 flaw with a CVSS score of 10.0 — the maximum possible — and a patch was publicly available within days of disclosure in March 2017. Attackers began exploiting it in the wild almost immediately. Equifax was still breached in mid-May, two months later, and didn't publicly disclose it until September, exposing roughly 147 million records. The information gap wasn't the problem — a CVSS 10 with active, reported exploitation is about as unambiguous a "patch this now" signal as security ever produces. The gap was that Equifax didn't know it was running the vulnerable component in the first place, which is an asset-inventory failure, not a threat-intelligence failure.

Building a priority signal that would have caught Equifax's exposure means combining four separate facts, not one:

• CVSS severity — how bad this is if exploited, from Software Composition Analysis in Depth.
• EPSS + KEV — the probability, and the confirmed fact, of exploitation happening right now, from this page's fifth section.
• Reachability — is the vulnerable function actually on a code path your application calls, or does it sit in a transitive dependency you import but never invoke? Modern SCA tooling (reachability analysis in Snyk, Endor Labs, and similar call-graph-based scanners) answers this directly instead of leaving it to guesswork.
• Exposure — is the affected service internet-facing, or reachable only from an already-trusted internal network with its own compensating controls?

Wiring it together: from threat intel feed to your own backlog

☺ Like you're 10: None of this helps if it only lives in someone's head. The whole point is a robot that checks the news every night and taps the right person on the shoulder before they've even opened their laptop.

Everything above becomes an actual capability, not a manual research exercise, once it's wired into a pipeline that runs on its own schedule. A concrete, realistic version: a nightly job pulls the CISA KEV JSON feed and the day's EPSS scores from FIRST.org's API, cross-references both against the organization's aggregated SBOM inventory — every component named in every service's SBOM, not just the ones a human remembers to check — and pushes any match into DefectDojo (see Vulnerability Management & Triage for the aggregation layer this plugs into) as a severity and SLA escalation, even against findings that were previously triaged and marked lower priority.

That last clause matters more than it looks. A finding a triager marked Risk Accepted three months ago, under the honest judgment "no known exploitation, low real-world likelihood," was a correct decision at the time — but that judgment has an expiration date the moment new evidence arrives. If that same CVE lands in the KEV catalog next Tuesday, the risk acceptance's underlying assumption is gone, and a backlog that doesn't automatically re-open and re-escalate that finding is running on a threat model that's already stale. This is the single strongest argument for automating the ingestion rather than relying on someone to remember to re-check old acceptances by hand.

This page sits between two halves of the same discipline: what a vendor owes you by design and by default, and what you do with the threat intelligence that tells you whether today's the day to actually act on it. For the internal backlog machinery this feeds into once a finding is triaged, see Vulnerability Management & Triage; for the SBOM inventory this page's cross-referencing depends on, see Software Bills of Materials; and for the maturity frameworks that turn "we try to do this" into something you can actually track, see Maturity Models: DSOMM, SAMM & BSIMM.