On April 13, 2023, CISA (the Cybersecurity and Infrastructure Security Agency), along with the FBI, NSA, and cybersecurity agencies from Australia, Canada, the UK, Germany, the Netherlands, and New Zealand, published "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure-by-Design and Secure-by-Default Software."
The document's central argument is radical in its simplicity: the burden of cybersecurity has been unfairly placed on end users, and it needs to shift to software manufacturers. If a product is insecure by default, that's the manufacturer's failure, not the customer's.
The Three Core Principles
1. Secure by Design
Software should be designed from the ground up with security as a core requirement, not an afterthought. This means:
- Threat modeling during the design phase
- Using memory-safe programming languages where possible
- Eliminating entire classes of vulnerabilities through architectural decisions
- Security reviews at every stage of development, not just before release
CISA specifically called out memory safety as a design priority, noting that memory-unsafe languages (C, C++) are responsible for approximately 70% of all vulnerabilities. The implication is clear: new software should be written in memory-safe languages (Rust, Go, Java, C#, Python) unless there's a compelling reason to use C or C++.
2. Secure by Default
Products should be secure out of the box, without requiring customers to take additional steps:
- Default configurations should be the most secure options
- Unnecessary features should be disabled by default
- Default passwords should not exist
- Logging and audit capabilities should be enabled by default, not sold as premium add-ons
The "secure by default" principle directly challenges common industry practices. Many vendors ship products with permissive defaults to minimize support tickets, then sell "security hardening" guides or premium security features.
3. Secure by Demand
Customers should demand security from their vendors:
- Ask vendors about their secure development lifecycle
- Require SBOMs as part of procurement
- Evaluate vendors based on their vulnerability disclosure and patch practices
- Include security requirements in contracts
This principle acknowledges that market forces drive vendor behavior. If customers demand secure products, vendors will build them.
What This Means in Practice
For Development Teams
The Secure by Design principles translate into concrete practices:
Adopt memory-safe languages for new projects. CISA isn't saying rewrite everything in Rust tomorrow. They're saying that when you start a new project, choose a memory-safe language unless performance requirements absolutely demand otherwise. And even then, isolate the unsafe code.
Eliminate default credentials. Every device and application should require unique credentials during setup. No more admin/admin out of the box.
Make security features standard, not premium. Multi-factor authentication, single sign-on integration, audit logging, and encryption at rest should be included in every tier of your product.
Implement secure update mechanisms. Products should update automatically by default, with the option to delay but not permanently disable updates.
Provide SBOMs. CISA explicitly mentions SBOMs as a component of transparency that manufacturers should provide.
For Security Teams
Shift left, but shift right too. Secure by Design doesn't just mean shifting security left into development. It means building security into operations, monitoring, and incident response.
Measure vulnerability classes, not just vulnerability counts. Track whether you're eliminating entire categories of vulnerabilities (SQL injection, XSS, buffer overflows) through design changes, not just patching individual instances.
Engage with procurement. Security teams should be involved in vendor selection and should evaluate vendors against Secure by Design principles.
For Executives
Security is a product quality issue. Secure by Design reframes security from a cost center to a quality indicator. Products with better security are higher quality products.
Liability is shifting. The document signals regulatory intent. Software vendors that don't implement secure practices may face increasing regulatory scrutiny and liability.
Competitive advantage. Organizations that can demonstrate Secure by Design practices will have an advantage in markets where customers are starting to demand evidence of security.
The Supply Chain Connection
Secure by Design is deeply connected to supply chain security:
You can't be secure by design if your dependencies aren't. Using a memory-safe language doesn't help if you're depending on a C library with buffer overflows. Secure by Design extends to your entire dependency chain.
SBOMs enable verification. Without an SBOM, how do you verify that a product was built with secure components? The SBOM is the mechanism that makes Secure by Design claims verifiable.
Transitive trust. When you claim your product is secure by design, you're implicitly claiming that your dependencies are also secure. That claim needs to be backed by evidence — dependency scanning, vulnerability monitoring, and ongoing assessment.
Industry Reaction
The response to the Secure by Design paper was mixed:
Security professionals overwhelmingly supported the principles, viewing them as long-overdue acknowledgment that the security status quo isn't working.
Software vendors had more varied reactions. Some embraced the principles publicly. Others expressed concern about the cost implications and the difficulty of retrofitting secure-by-default configurations into existing products without breaking customer deployments.
Open-source maintainers raised questions about how these principles apply to volunteer-maintained projects. If a solo maintainer writes a library in C, are they now responsible for "secure by design" outcomes?
Looking Forward
The Secure by Design paper is not a regulation. It's not enforceable. But it's a strong signal of where regulatory pressure is heading. CISA has significant influence over federal procurement, and federal procurement requirements tend to become industry standards.
Organizations that start implementing Secure by Design practices now will be ahead of the curve when these principles become requirements — whether through regulation, procurement mandates, or customer demands.
How Safeguard.sh Helps
Safeguard.sh helps organizations implement and demonstrate Secure by Design principles:
- SBOM Generation: Safeguard.sh generates comprehensive SBOMs that document every component in your software, supporting the transparency CISA calls for.
- Vulnerability Monitoring: Safeguard.sh continuously monitors your dependencies against vulnerability databases, helping you maintain a secure dependency chain as part of your Secure by Design approach.
- Compliance Reporting: Safeguard.sh generates reports that demonstrate your software composition and security posture, supporting procurement discussions and regulatory compliance.
- Dependency Risk Assessment: Safeguard.sh evaluates the security posture of your dependencies, helping you make informed decisions about which components meet your Secure by Design standards.
Secure by Design isn't just a government initiative. It's the direction the entire industry is moving. The sooner you build these practices into your development lifecycle, the better positioned you'll be.