The Product Security Imperative: Lessons from CISA

The Product Security Imperative: Lessons from CISA

Speaker: Jack Cable

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: https://www.youtube.com/watch?v=aak3A_ObCiE

Reading time: 7 minutes

TL;DR

Jack Cable, who spent two years at CISA leading the Secure by Design initiative before delivering this talk, made the case that the software industry is still building products riddled with decades-old, preventable vulnerability classes — and that addressing them requires shifting liability from end users onto technology manufacturers. His talk reviewed the year-one results of CISA's Secure by Design pledge, the case for legal reform to protect security researchers, and the specific threat that AI-assisted coding poses to product security in the near term.

Introduction

When CISA launched its Secure by Design initiative in 2023, it was asserting something that many security practitioners already believed but few federal agencies had said so plainly: the cybersecurity problem is, at its root, a product quality problem. The organizations being breached most often — hospitals, schools, small businesses, critical infrastructure operators — are not failing because their staff are incompetent. They are failing because the software they depend on ships with memory safety vulnerabilities, SQL injection flaws, and hardcoded credentials that have been technically preventable for decades.

Jack Cable, speaking at BSidesSF 2025 in his first public talk since leaving CISA, gave the audience a detailed look at what the Secure by Design effort accomplished, where it fell short, and what he believes needs to happen next. His perspective was shaped by two years inside a federal agency navigating the gap between policy ambition and industry inertia — and it was notably more candid than the institutional messaging that accompanied the initiative when he was still at CISA.

▶ Watch: Introduction and CISA Background (00:00)

The Secure by Design Pledge: Origins and Mechanics

CISA launched the Secure by Design pledge in May 2024, building on the White House's 2023 National Cybersecurity Strategy, which called for a "fundamental shift in the burden of cybersecurity responsibility" — away from end users, small businesses, and hospitals, and onto the technology manufacturers best positioned to prevent vulnerabilities at the source.

Cable described the internal process of getting industry buy-in as multi-month and contentious. The initial reaction from many companies was blunt: "This is great, but we'd never commit to this. What's in it for us? We're not going to just go and do this because this will cost us a lot, and there's no value to it." The mechanism that ultimately moved the needle was peer pressure rather than regulation — once competitors began signing, holdouts faced the question of why they hadn't. The pledge launched with 68 initial signatories and has since grown to over 300 companies.

▶ Watch: Secure by Design Pledge Origins (02:00)

The pledge commits companies to seven goals over one year, including increasing multi-factor authentication adoption, reducing default passwords, reducing entire classes of vulnerabilities, and publishing transparent progress reports. The one-year reporting deadline — May 8, 2025, roughly two weeks after this talk — was approaching with only about 30 progress reports published from the 300-plus signatories. Cable acknowledged the shortfall but framed the reporting requirement as an accountability mechanism and a way for companies making genuine progress to distinguish themselves publicly.

What the Vulnerability Data Actually Shows

To ground the conversation in specifics, Cable walked through a MITRE analysis of CISA's Known Exploited Vulnerabilities (KEV) catalog. The finding was stark and familiar: memory safety vulnerabilities dominate the top exploited vulnerability classes, followed by command injection, SQL injection, server-side request forgery, and path traversal. Cable's observation was pointed: "If you went and showed this list to someone maybe twenty years ago, they'd say, 'Oh yeah, that looks about right.'"

That unchanged composition is the core indictment. The software industry has known how to prevent these vulnerability classes for decades. MySQL introduced parameterized queries — the standard mitigation for SQL injection — in 2000. The 2023 MOVEit breach, which compromised hundreds of organizations, was a SQL injection vulnerability. The attack surface is not exotic; it is the same terrain that developers have been warned about since the early 2000s.

▶ Watch: Vulnerability Classes and Root Causes (08:01)

The memory safety argument received particular emphasis. Cable cited Android's longitudinal data showing that as Google introduced memory-safe programming languages into the Android codebase, the proportion of memory safety vulnerabilities in Android declined steadily — even while the legacy C/C++ code remained in place, because attackers preferentially target new code. The implication: companies building new products today in C or C++ are making a choice that will produce predictable, preventable vulnerabilities. Languages like Rust offer a path that is increasingly practical, even if migration of existing codebases is expensive.

Progress Reports and Industry Response

Cable reviewed specific company progress reports to illustrate both the achievements and the gaps. On the positive side: all three major cloud platforms — Microsoft Azure, Google Cloud, and AWS — have made multi-factor authentication mandatory across their platforms. That single change represents enormous leverage given the number of organizations running critical workloads on those platforms.

Google published a white paper demonstrating that certain product lines have eliminated SQL injection and cross-site scripting vulnerabilities entirely through framework-level controls rather than developer vigilance. Fortinet published data on the adoption impact of enabling automatic updates — showing a significant spike in the proportion of customers running current versions, though also revealing that some customers actively disabled automatic updates and reverted to older software.

▶ Watch: Progress Reports from Pledge Signatories (12:01)

Fortinet's transparency about the update-disabling behavior exemplified what Cable described as "radical transparency" — a principle articulated in CISA's Secure by Design white paper that calls for companies to publish honest accounts of where their security improvement efforts are falling short, not just where they are succeeding. "That level of transparency is exactly what's needed," Cable said.

Legal Reform: Protecting Security Researchers

Cable co-published a piece with former CISA director Jen Easterly on the day before the conference advocating for reform of U.S. anti-hacking laws. His argument: Secure by Design depends on security researchers being able to find and disclose vulnerabilities in products, and current law makes that dangerous.

Two statutes are the focus. The Computer Fraud and Abuse Act (CFAA) and the Digital Millennium Copyright Act (DMCA) both create legal exposure for good-faith security research. The DMCA situation is particularly convoluted: an existing exemption for security research must be re-enacted every three years through a proceeding before the U.S. Copyright Office, which sits inside the Library of Congress, and the exemption must be re-argued from scratch each cycle. Cable called for codifying the exemption into statute rather than leaving it to a triennial administrative proceeding.

▶ Watch: Legal Reform and Vulnerability Disclosure (18:01)

An audience question noted that state-level anti-hacking laws — citing Missouri, Ohio, and Texas as recent examples — are often more restrictive than federal law. Cable agreed and encouraged attendees to research the anti-hacking laws in their own states, noting that room for improvement is universal. Belgium was cited as a positive example: it enacted legal changes explicitly exempting good-faith security research from its anti-hacking statutes.

Cable also called for the FTC to establish minimum baseline requirements for software manufacturers above a certain size — drawing an analogy to aviation's NTSB incident database and the automotive industry's safety recall infrastructure. As a near-term step, he advocated for expanding CVE adoption, including requiring companies to file CVEs for SaaS vulnerabilities that do not require end-user action, and including root-cause information via Common Weakness Enumeration (CWE) fields in CVE records.

AI-Assisted Coding: Making the Problem Worse

Cable closed with a warning about a trend accelerating in real time. AI coding assistants — Cursor, GitHub Copilot, and similar tools — are dramatically expanding both the volume of code being written and the number of people writing it. Neither of those trends is security-positive.

The code these tools generate has been trained on the same corpus of insecure code that humans have been writing for decades. The tools do not consistently produce secure outputs. Meanwhile, the people writing code with AI assistance include many who have no security background and no peer review process in place. The combination — more code, less expertise, weaker review — will produce more vulnerabilities, Cable argued. "I don't think we're at the point where these AI assistants are gonna be outputting perfectly secure code. I think we're far from that."

▶ Watch: AI Coding and Future Security Risks (22:01)

The implication for Secure by Design is that the baseline expectations being set now — no memory unsafe languages for new products, no direct user input to SQL queries, no hardcoded credentials — matter more, not less, as AI-generated code proliferates. Without those guardrails at the framework and tooling level, the expansion of AI-assisted development will amplify the same vulnerability classes that have dominated the KEV catalog for two decades.

Notable Quotes

"The vast majority of cybersecurity attacks get in not through the mistakes that end users are making, but all too often due to either an insecure default configuration or a vulnerability that is ultimately preventable." — ▶ 04:00

"Why wasn't there a secure default password in the first place? Why was this SQL injection or memory safety vulnerability present when we've known how to prevent these vulnerability classes for decades?" — ▶ 04:00

"I don't think we're at the point where these AI assistants are gonna be outputting perfectly secure code. I think we're far from that — and we know they've been trained on datasets of insecure code that people have been writing for decades." — ▶ 22:01

Key Takeaways

• The top exploited vulnerability classes in 2025 are the same as they were twenty years ago — memory safety issues, SQL injection, command injection — because the industry has not systematically eliminated them at the product manufacturing level.
• The Secure by Design pledge has achieved real wins, including mandatory MFA across all major cloud platforms and the elimination of entire vulnerability classes in some product lines, but reporting compliance is low and accountability mechanisms remain weak.
• U.S. anti-hacking laws (CFAA, DMCA) create legal risk for good-faith security research and should be reformed to explicitly exempt security researchers, as Belgium and other countries have already done.
• AI-assisted coding is likely to expand the attack surface, not reduce it, because the tools are trained on insecure code, deployed by developers without security background, and produce output that is not systematically reviewed.
• Security researchers are the third-party auditors of product security — their ability to work safely and disclose findings responsibly is essential infrastructure for Secure by Design to function at scale.