OneStart

CISA’s Secure by Design Explained for Business Leaders and Teams

CISA’s Secure by Design Explained for Business Leaders and Teams

Do the apps in your enterprise stack put your organization’s security first? You expect new software to protect your sensitive details and critical systems and leverage secure libraries and toolchains. But is that usually the case? What’s in those T&Cs, anyway?

It’s not just software developers and security teams who should understand CISA’s Secure by Design framework [1]. Leaders, procurers, product owners, designers, marketers, and policy-makers all need to grasp the basics of Secure by Design to understand how choosing these products helps protect the business.

Insecure apps and services can seriously damage your organization: disrupting operations, leaking sensitive IP, affecting revenues, eroding brand reputation, breaching compliance terms, and costing significant amounts in remediation.

“On average, only 54% of major code changes for applications undergo a full security review before deploying to production.” [2]

If your organization cares about cybersecurity, choosing Secure by Design software matters.

Secure by Design: Building Safety from the Ground Up

Secure by Design isn’t just a marketing buzzword. True Secure by Design software follows CISA’s Secure by Design principles, released in 2023.

Secure by Design means that security is considered and built into a product from the very beginning—from the first line of code to ongoing security updates through to product end-of-life.

Software and services built Secure by Design help provide quality assurance in software safety, reliability, and – most importantly – security.

Key Points:

  1. The goal is to reduce the number of vulnerabilities before the product is even launched.
  2. Security is part of the initial design process, not added later.
  3. Builds in security throughout design, development, controls, reporting, and company disclosures.
  4. Offers a more secure product out of the box.
  5. Provides consumer confidence in vulnerability reporting, tracking, and patching.
  6. Helps build a more robust, secure software ecosystem.

What it looks like in practice:

  • Writing code with safety in mind (e.g. avoiding unsafe functions).
  • Using secure development practices like threat modeling and code reviews.
  • Designing the architecture to minimize risks (e.g. segmenting sensitive data).
  • Publishing security benchmarks and reports, company security goals and accreditations.

The Secure by Design framework is developed by the Cybersecurity and Infrastructure Security Agency (CISA) USA, and is recommended by the Australian Cyber Security Centre (ACSC), the Canadian Centre for Cyber Security (CCCS), the United Kingdom’s National Cyber Security Centre (NCSC-UK), and more.

Software should be Secure by Default

Secure by Default is what you receive at the point of delivery. It means that when users install or start using a product, it’s already set up with the safest settings turned on, without extra work or deep technical knowledge needed, or an additional charge.

When you buy a new washing machine, you expect it to be safe, that it won’t shock you or short-circuit the power supply. It comes certified with safety compliance badges, insulated cording, and is designed to separate water from electricity.

Unlike the washing machine, unsafe software isn’t a threat to physical health but it’s a threat to your organization’s digital health. Proof of safety in software can look a lot like safety in a washing machine: compliance badges, rigorous testing, safe design decisions, and component hardening.

What it looks like in practice:

  • Passwords with MFA are required and must meet strong standards.
  • Encryption (like TLS) is automatically turned on for all network communications.
  • Admin access is limited unless explicitly granted.
  • Audit logs and security alerts are already active.

CISA’s Secure by Design framework offers compliance assurance to help you identify a safe, secure software product, with resiliency against exploits out of the box. It’s Secure by Default: resilient against exploits out of the box, without added charge.

Demanding better from your vendors

“26% of organizations say that vulnerabilities in complex supply chain interdependencies present the greatest challenges in cybersecurity” [3]

Application and infrastructure security shouldn’t be an add-on subscription. You shouldn’t need additional vulnerability-checking software outside of your current tooling. You should be able to trust software not to compromise or exploit your enterprise environment. Sandboxing everything and trusting users to understand the security implications of their actions is just not viable.

CISA’s Secure by Design principles

CISA’s Secure by Design Principles is a guide to embedding security in software manufacturing.

The document outlines three principles, each with practical software controls, development paradigms, and business practices, and their resulting artifacts, for provable security.

PRINCIPLE 1: Take Ownership of Customer Security Outcomes

The first principle describes customer security as a key design consideration in app development, not an afterthought.

For example, a product should encrypt a database storing personally identifying data by default, rather than having it as an additional setting for a user to toggle in an app. That means the company that made it has done the hard work to protect the user before the product even gets installed.

In simple terms: Make security the company’s job, not the customer’s.

Automox, an endpoint security product, requires multifactor authentication by default, with password and email code confirmation.

PRINCIPLE 2: Embrace Radical Transparency and Accountability

The second principle stipulates publishing internal security metrics as a matter of transparency.

Instead of hiding issues or pretending everything’s operating smoothly, companies should show their work. That means publishing information like:

  • What security tools and frameworks they use,
  • How often they run security checks,
  • How many bugs they’ve fixed,
  • And how people can report new problems (aka a Vulnerability Disclosure Policy).

For example, a developer may publish the number of intrusion attempts on their suite of products.

Why does this matter? Because it builds trust. When a company is upfront about how it keeps your data safe and how it handles issues when things go wrong, you’re more likely to believe they care about your security. It also helps other tech teams learn from each other and raise the bar for the whole industry.

Developers can use Microsoft’s free sbom-tool (Software Bill of Materials) to create a list of dependencies to share with potential customers for peace of mind in software supply chain security.

PRINCIPLE 3: Build Organizational Structure and Leadership to Achieve These Goals.

The third principle enshrines cyber responsibility throughout the organization.

Security here applies to corporate cyber responsibility, updates to company mission and values, ongoing programs, and councils.  This principle is about making sure there are people and systems in place inside the company to actually follow through on Secure by Design in practice.

In other words, don’t just write these principles on a poster and stick it on a wall. Companies need actual teams, budgets, and leadership that are focused on making these security promises a reality every day, not just when there’s a crisis.

If a company doesn’t have the right people or structure, even the best security ideas will fail. This principle is about setting up the business so that reliable security will happen, and someone is accountable.

Moveworks, a Secure by Design developer, includes an extended Trust and Security page on their website, including a dedicated AI security and privacy by design section.

CISA’s Secure by Design pledge for vendors

You can easily identify software vendors that are committed to producing Secure by Design software and services, as they have taken CISA’s Secure by Design Pledge.

The pledge covers seven security goals for all Secure by Design projects:

  1. Multi-Factor Authentication by default
    Implementing two or more authentication methods for all product access attempts (e.g. password, Authenticator app, fingerprint).
  2.  Elimination of default passwords
    Removing default passwords from initial product setups, or requiring an immediate password change on setup.
  3. Removal of common vulnerability types
    Removing the most common vulnerability vectors from the software (e.g. applying the OWASP Top Ten Web Application Security Risks standard).
  4. Security patches
    Automatically installing software patches, with special attention to security patches.
  5. Vulnerability disclosure policy
    Publication of a Vulnerability Disclosure Policy, that gives permission for the public to test the product without legal repercussions and states that the company will disclose any known vulnerabilities. See CISA’s Vulnerability Disclosure Policy Template for more info.
  6. Common Vulnerabilities and Exposures (CVE) record
    Publication of the company’s Common Vulnerabilities and Exposures (CVE) record, including identifying and scoring weaknesses and platforms for common vulnerabilities.
  7. Demonstrated evidence of intrusions
    Offering customers ways to identify intrusions within the product, such as built-in event logging and notifications for significant events.

Discover manufacturers who take Secure by Design seriously

Manufacturers such as Zscaler, Tenable, Lumos, and GitHub offer proof that their software is Secure by Design by taking CISA’s Secure by Design Pledge.

You can also query these companies in their dedication to Secure by Design by checking if they are following all the advice outlined in the Secure by Design document, not just the goals under the pledge.

Hundreds of companies have taken the Secure by Design pledge. View the full list of software companies that are taking application security seriously here.

For a detailed insight into the seven goals of the Secure by Design pledge and how businesses are achieving them, read Microsoft’s Secure by Design journey: One year of success.

Champion Secure by Design within your organization

If a company only focuses on Secure by Default, the product might ship with safe settings—but still have hidden weaknesses under the hood with vulnerabilities in the code.

That’s why both principles matter. Secure by Design protects the foundation. Secure by Default protects the user from the very first product use.

You can help your organization become more cybersecure by selecting Secure by Design vendors, auditing your current vendor list,  and creating procurement guidelines that give preference to software that’s Secure by Design.

Cybersecurity is everyone’s responsibility, but education has to start somewhere. You don’t have to be a security team member to be a security champion within your organization.

Make a commitment to change, start a working group, and develop mature frameworks for evaluation, procurement, and review of the tools that run your organization.

References:

  1. CISA Secure by Design
  2. 2024 State of Application Security Report, Crowdstrike
  3. Global Cybersecurity Outlook 2025, World Economic Forum
  4. CISA’s Secure by Design Pledge

About the Author

Julia Sinclair is a technology author and software developer with specialized expertise in enterprise cybersecurity, infrastructure, code, and emerging tech. Julia has created strategic content for the world’s largest tech brands, through to AppSec startups, with a systems mindset that maps underlying methods to the end magic.

Scroll to Top