CISA Secure by Design: The Shift from Compliance to Structural Safety

CISA's Secure by Design Is a Challenge to the Compliance Model

CISA's "Secure by Design" initiative (launched April 2023, updated August 2024) is notable for what it argues against as much as what it advocates for. The guidance explicitly challenges the compliance-as-security model: meeting a checklist does not make software secure.

The alternative framing: secure software is structurally safe. It's built in a way that makes entire classes of vulnerabilities impossible or impractical, not a way that passes a scan.

The Three Core Principles

1. Take Ownership of Customer Security Outcomes

Secure by Design places responsibility for security outcomes on software producers, not users. If an enterprise customer is breached because they failed to enable an optional security feature in your product, that's a product design failure, not a user failure.

In code terms: security should be the default, not an option. Encryption on, authentication required, audit logging active. These are not features users enable. They're baseline behaviors.

2. Embrace Radical Transparency and Accountability

CISA asks software producers to publish CVE counts, time-to-remediation metrics, and security testing methodologies. The goal is accountability through data: organizations making purchasing decisions should be able to evaluate the security posture of software they're buying.

For development teams, this means maintaining data about security findings and their lifecycle, which requires tooling that captures this data systematically.

3. Build Organizational Structures and Leadership

Secure by Design pushes security into product leadership accountability, not just engineering. Security issues should be tracked at the same level as performance regressions and reliability incidents.

The Memory Safety Argument

A significant portion of CISA's Secure by Design guidance focuses on memory safety. CISA, NSA, and allied agencies have jointly issued guidance recommending that new software development use memory-safe programming languages for components that process untrusted input.

The argument: buffer overflows, use-after-free, and related memory safety bugs (CWE-119 family, CWE-416) account for roughly 70% of exploited vulnerabilities in Microsoft and Chrome. These vulnerabilities are structurally impossible in memory-safe languages (Rust, Go, Swift, Java, Python). Not less likely, but impossible.

For organizations with existing C/C++ codebases, this doesn't mean rewriting everything. It means:

• New components default to memory-safe languages
• Unsafe interfaces to C code are isolated and minimized
• Memory safety tooling (sanitizers, fuzzing) is applied to remaining C/C++ code

The Default Security Configuration Problem

CISA's 2023 "Security-by-Design and -Default" guidance with NSA, FBI, and partner agencies identified insecure default configurations as a top attack enabler. The guidance directly addresses software vendors: stop shipping products with weak default configurations that require customers to harden.

In application code, the equivalent is frameworks and libraries that ship insecure defaults. Django's CSRF protection is on by default; that is Secure by Design. Express.js's CORS allows all origins by default; that is not. The framework defaults propagate through every application built on them.

How Deva Addresses Secure by Design

Deva's scanner checks for insecure default configurations across popular frameworks (Express.js, Flask, FastAPI, Spring Boot) and surfaces findings where framework defaults create vulnerability exposure. The OWASP preset covers Security Misconfiguration (A02:2025) and the rest of the 2025 categories.

Compliance presets that reference CISA Secure by Design principles (NIST CSF 2.0, CMMC 2.0) include findings mapped to the structural safety properties CISA identifies.