DevSecOps and Secure by Design: What CISA Asks of Software Makers

TL;DR: The Cybersecurity and Infrastructure Security Agency (CISA) asks software makers to take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top, shipping products that are secure out of the box with security features at no extra cost. DevSecOps builds security into the delivery pipeline, but it cannot settle pricing or executive ownership. The Secure by Design pledge is voluntary, so buyers can ask for dated, checkable evidence rather than a signature.

What is DevSecOps, and what does Secure by Design add to it?

DevSecOps changes how an engineering team builds and ships code. Secure by Design changes who pays for insecure software. The first works inside the pipeline. The second reaches the product roadmap, the price list and the executive team.

Microsoft defines DevSecOps as an approach that integrates security into every phase of the DevOps lifecycle. It embeds automated controls in continuous integration and continuous delivery (CI/CD) pipelines instead of holding a final review before release. It also makes security a shared responsibility. The DevSecOps manifesto states the same idea from the security team's side: practitioners will operate like developers and offer security and compliance as services that engineers can consume.

Secure by Design starts from a different problem. CISA says the country has allowed a system where the cybersecurity burden is placed disproportionately on the shoulders of consumers and small organizations. Its remedy is addressed to leadership, not to tooling: "Every technology provider must take ownership at the executive level to ensure their products are secure by design."

The CISA guidance has already gone through one revision. Its authors collected feedback after the release in April 2023 and expanded the text in response.

A concrete case: single sign-on

Take a team with a mature DevSecOps pipeline. It scans, tests and signs a new single sign-on (SSO) feature and ships it with no known flaws. The company then sells SSO only on its enterprise tier. Every gate in the pipeline passed, yet a customer on the basic plan still has no SSO.

CISA says products should be secure out of the box, with multi-factor authentication (MFA), logging and SSO available at no extra cost. Whether to charge for SSO is a packaging decision, and no pipeline gate makes packaging decisions.

In our reading, this is the main thing Secure by Design adds. It moves part of the security question out of engineering and into product management, pricing and the boardroom. DevSecOps remains one way to meet those commitments, but it does not stand in for them. We think a security leader should also expect some releases where the Secure by Design view means a feature waits, even when the pipeline says it is ready.

The three principles CISA asks software makers to follow

In our reading, the version most makers now work from is the update the Cybersecurity and Infrastructure Security Agency (CISA) and 17 U.S. and international partners published on October 25, 2023. It brought in eight new international agency co-sealers. The authors say the most common request in the feedback on the first version was for more detail on the three principles, for makers and customers alike.

The update adds a stress on proof a customer can see. CISA says it shows "how software manufacturers can demonstrate these principles to their customers and the public". It also says makers "must be able to compete on the basis of security."

The scope also reaches past conventional code. The authors state that "the three overarching secure by design principles apply to all AI systems", meaning artificial intelligence (AI) systems and models.

What each principle looks like in practice

The third column is our reading, not text from the guidance. The guidance describes intent. A buyer needs an artifact.

In our reading, the third principle is the one that makes the other two hold. A memory-safety plan or an honest advisory program costs engineering time that competes with features. Without an executive who owns that trade-off, it tends to slip. Our board committee oversight report covers how directors take up that kind of reporting.

For a security leader assessing a supplier, the practical step is to ask for one piece of evidence per principle: a roadmap, an advisory archive and a named owner. In our reading, if a vendor can produce all three, that tells you more than a signed statement of support. Our guide on CISO accountability covers the same ownership questions from the buyer's side.

Secure by design and secure by default are two different things

The two halves of the slogan ask for different work. Design is about how a product is conceived and built. Default is about the state it arrives in when a customer switches it on.

Design tactics: decisions made before code exists

Manufacturers should "perform a risk assessment to identify and enumerate prevalent cyber threats to critical systems", and the agencies recommend "a tailored threat model during the product" development stage.

Some of this work never shows up in a feature list. The paper gives the example of "migrating to programming languages that eliminate widespread vulnerabilities."

Default tactics: the state a product ships in

Default is narrower and easier to test. The updated edition describes such products as "secure to use “out of the box” with little to no configuration changes necessary, and security features available without additional cost." A buyer can check this directly. Install the product and look at what is already on. Then look at which security features sit behind a paid tier.

The updated edition also notes that "The term “secure by design” encompasses both secure by design and secure by default." When a vendor uses the short form, it is fair to ask which half they mean.

Hardening versus loosening guides

Our reading: a hardening guide puts the work of securing a product on the customer, while a loosening guide ships the product secure and documents the risk of each setting a customer relaxes.

What changed between editions

The update did not replace the design and default tactics. It answered the most common feedback, which asked for more detail on the three principles "as they apply to both software manufacturers and their customers." In our reading, the shift from principles to philosophies matters less than the added material for customers. That material gives buyers more to ask vendors about.

What the Secure by Design pledge commits a company to

The pledge is short to describe. On its Secure by Design hub, the Cybersecurity and Infrastructure Security Agency (CISA) invites software makers to join by "committing to take specific, measurable actions in line with secure by design principles". That phrase carries the weight. The pledge is a promise to act and to show the action. It is not a certificate or an audit.

In our reading, The pledge is voluntary. In our reading, nothing on the CISA pages cited here makes signing a condition of selling software, and nothing describes an inspection of signers. A company chooses to sign. In our reading, most of the public record of what it has done afterward comes from the company itself.

That makes the pledge a statement of intent, backed by the signer's own disclosures. CISA's hub sets the tone at the top: "Every technology provider must take ownership at the executive level to ensure their products are secure by design." We think a pledge with no named executive behind it says less than one an executive has put their name to.

What a reader can check

This section describes what the pages say. It is not advice on whether a company should sign or what signing obliges it to do. A reader can check the following.

Turning a pledge into procurement questions

The customer side has its own document. CISA describes its Secure by Demand guide as "concise and usable by any customer of software during procurement discussions with third party resellers or service providers". In our reading, that guide is the natural bridge from a vendor's public pledge to the questions your team asks in a renewal.

A practical sequence:

1. Ask the vendor for its most recent published progress update, with a date on it.
2. Match each claim to a pledge action. Note any action with no claim against it.
3. Look for evidence a customer can verify, such as a setting you can see in your own tenant.
4. Record the answers in your vendor file, next to the contract terms. Our vendor pages can help with context on a supplier.

A signature on its own tells you little. The dated, checkable progress behind it tells you more. Questions about the program itself can go to CISA at SecureByDesign@cisa.dhs.gov.

DevSecOps, Secure by Design and the SSDF compared

The three names often appear together in procurement questionnaires, but they are different kinds of document. Sorting them by author, audience and the paper trail each one leaves makes the differences plain.

The SSDF describes itself as a core set of high-level secure software development practices that slot into an existing software development life cycle (SDLC). In our reading, it is the only one of the three with numbered tasks, so it is the easiest to audit.

In our reading, Secure by Design moves more often. After the first release, CISA and its partners received feedback from hundreds of individuals, companies, and trade associations and said they intend to convene a series of listening sessions to refine it. In our reading, a team that maps its controls to the current version should plan to check it again.

DevSecOps against plain DevOps

DevOps, short for development and operations, emphasizes automation, faster release cycles, and shared ownership of application performance. DevSecOps adds security to the same workflow. In Microsoft's worked example, the pipeline adds automated vulnerability scanning, secrets detection, dependency analysis, and policy checks before deployment proceeds.

The manifesto puts the cultural side bluntly. Its authors say they will favor iteration over trying to always come up with the best answer before a deployment. That stance suits a pipeline. In our reading, it gives a board less to review than a dated, versioned framework does.

How they fit together, in our reading:

• DevSecOps is how the work gets done day to day.
• The SSDF is the checklist that shows the work was done.
• Secure by Design says who answers for the outcome, which is why the earlier sections stressed executive ownership.

A security leader who runs DevSecOps well can still struggle to answer an SSDF questionnaire if the pipeline evidence is not kept. Terms used here are defined in our glossary.

What makes DevSecOps practices stick with developers

Most DevSecOps programs are built from the same parts. The differences lie in how those parts reach the people writing code.

Code analysis starts early. In Microsoft's overview, automated scans check for exposed credentials and vulnerable packages as code is committed. At the build stage, continuous integration pipelines run static analysis, software composition analysis and artifact signing.

Policy as code turns written rules into checks a machine can run. The same overview describes infrastructure-as-code templates validated against policy-as-code controls before deployment. It also says policy as code enforces standards aligned to frameworks from the International Organization for Standardization (ISO), System and Organization Controls (SOC) and the National Institute of Standards and Technology (NIST), and that this supports audit readiness.

Change and compliance management meet the pipeline at that point. The log of what passed and what was blocked becomes the audit trail. Nobody has to rebuild it later from tickets.

The software bill of materials (SBOM) is an inventory of the components and dependencies inside a release. It fits alongside dependency analysis.

Why some programs fade

Microsoft lists tool sprawl, skill gaps, compliance complexity, and AI-generated code risk among common challenges. It also says success truly depends on how teams apply the tools. The DevSecOps manifesto commits its authors to remediation actions instead of long lists of problems and says they won't simply rely on scanners and reports. AWS presents automation as a way to keep the security assessment from being a bottleneck.

Our reading is that tool sprawl and long finding lists push developers away faster than any single control does. Each new scanner adds its own dashboard, login and severity scale. A report of several hundred findings with no owner and no fix gets filtered out, and later ignored.

We think the practices that last are fixes delivered in the developer's own workflow. Examples include a suggested patch in the pull request, a failed check that names the line and the rule, or a dependency bump opened as a ready-to-merge change. A security leader can test this directly. Count the places a developer must visit to see security results, and ask how many findings arrive with a proposed fix attached.

Steps a sitting security leader can take this quarter

The four steps below are our own view of what a security leader can start inside one quarter. They draw on the Cybersecurity and Infrastructure Security Agency (CISA) customer recommendations and the Secure Software Development Framework (SSDF). None needs a new budget line, and each produces something you can show.

1. Ask vendors for evidence, not promises

At renewal and in procurement, ask each software supplier how it applies the three principles to the product you buy. CISA expects gradual movement: "Existing products can evolve to a secure by design state over multiple iterations" (CISA). In our reading, that makes a dated plan a fair ask, rather than a finished state.

Products with AI features are covered too. CISA says the report "applies to manufacturers of artificial intelligence (AI) software systems and models as well" (CISA).

Questions to put to a supplier (our reading):

• Which security features are on by default, and which cost extra.
• How it traces past vulnerabilities to root causes.
• Which SSDF practices it can show evidence for.

File the answers with your vendor records so the next renewal starts from the last reply.

2. Map your own pipelines to the SSDF

The National Institute of Standards and Technology (NIST) notes that "Few software development life cycle (SDLC) models explicitly address software security in detail" (NIST). NIST also publishes the SSDF practice table as an Excel spreadsheet (NIST).

Take that spreadsheet and add one column per build pipeline. Mark each practice as automated, manual or missing. The missing rows become next quarter's backlog, and the automated rows become evidence for auditors.

3. Pick two default settings to change

Choose two settings on internal platforms that today depend on someone remembering to harden them. CISA ties defaults to fewer incidents "resulting from misconfigurations, insufficiently fast customer patching, or many other common issues" (CISA).

Candidates, in our reading: multifactor authentication on by default for administrator accounts, and audit logging switched on at provisioning. We think two changes are enough to prove the pattern and measure the result.

4. Put the work in board language

In our reading, boards follow cost and ownership more readily than tool names. CISA describes the old model plainly: manufacturers fixed flaws after deployment, "requiring the customers to apply those patches at their own expense" (CISA). That framing turns a technical topic into money and staff time.

Be candid about pace. CISA concedes that aligning an SDLC with the principles "is not a simple task and may take time" (CISA). Report three quarterly items: vendor answers received, SSDF gaps open, and the two default changes made. For how committees receive this kind of reporting, see our board committee oversight report and the glossary entry on board cybersecurity oversight.

What this guide does not cover

It describes what CISA and NIST documents say and what a reader can check, and it is not legal advice on whether a company should sign the Secure by Design pledge or what signing obliges it to do. For the rules and the record behind it, see What Does a CISO Do? Responsibilities, Reporting Lines and Required Skills.