The Race to Make a Business of Secure Defaults

Modern, engineering-oriented security teams have increasingly used “secure defaults” to scale their programs. More recently, government organizations and major technology companies have lent weight to this approach.

• The UK’s NCSC has pushed Secure by Design principals since 2019

• Meta’s 2019 Designing Security for Billions highlights "Secure frameworks”

• Netflix is known for their Paved Roads approach, or “Guardrails over Gates”

• CISA launched new Secure by Design guidance in 2023

• Secure by Design at Google was published in March 2024

• CISA followed up with the secure by design pledges in May 2024

At their core, these share a fundamental approach to security: that security should make it easy for developers to work safely, while adding guardrails against insecurity. They leverage frameworks, tools, libraries, culture, and processes to implement this goal.

Characteristics of Secure Defaults

There are a set of unifying characteristics across secure defaults:

1. Proactive, not reactive: Secure default approaches should focus on prevention rather than correction. The goal is to funnel users to the secure approach, removing any potential gap in security or thrash when issues are detected reactively.

2. Prescriptive, yet flexible: These methods dictate safe practices, they also accommodate flexibility. Allowing for deviations within the paved roads avoids encouraging off-roading.

3. Invisible: The ideal secure default approach can seamlessly integrate security into users’ regular operations.

4. Extensible: Secure defaults should be are built to accommodate changes and growth in the system without compromising security. You should be able to add additional controls, and also extend controls to new systems.

5. Migration paths: To encourage adoption, secure defaults need to consider the migration path and integration points with existing solutions.

Secure Applications, Secure Infrastructure, Secure Endpoints

The three most prominent places I’ve seen secure defaults implemented are in Application Security, Infrastructure Security, and Endpoint Security.

Application Security

Abhay Bhargav already collected a variety of examples back in his 2020 A List of Secure Defaults. Some of my favorites are:

• Google's Tink - “secure, easy to use correctly, and hard(er) to misuse” cryptogtaphy

• Mustache - “logic-less templates,” great for preventing server-side template injection

• Django’s Cross Site Request Forgery protection middleware

Google also recently expanded their “Family of Safe Golang Libraries” - including SafeOpen, SafeYAML, and SafeArchive

The flexibility of custom Semgrep rules lend themselves nicely to nudging developers to use secure libraries or code patterns, and away from dangerous ones.

• I wrote about using Semgrep for Terraform Security, giving examples of replacing overly flexible default modules with custom, secure-by-default ones (secure-bucket, safe-proxy-access).

• Sid Adukia gave an example of finding authorization bugs in apps using Ruby’s Pundit gem, and the Semgrep docs give examples of flagging business logic issues, recommending secure libraries, and more.

Infrastructure Security

In infrastructure, Netflix has published examples extensively, including their use of Spinnaker for safe Continuous Delivery and their Wall-E gateway.

Dropbox has spoken about their identity aware proxy for internal applications, an approach that was duplicated at Figma.

A basic primitive I often see is creation and use of secure by default Terraform modules. asecure.cloud has published numerous examples.

Teams may also create Golden AMIs as a secure baseline.

Endpoint Security

Powerful secure defaults are available, including:

• The use of Chromebooks for high risk teams, to minimize the endpoint attack surface

• Application allowlisting, through tools like google/santa

Are Secure Defaults Differentiated?

I’ve worked in multiple organizations applying secure defaults, and spoken with engineers and security practitioners at dozens more. Fundamentally, it seems like many secure defaults are undifferentiated. You can see this in the broad adoption of open-source secure defaults - like those in application security. I’ve also observed security teams constantly building the same thing within each company, e.g Figma’s reproduction of Dropbox’s identity aware proxy.

“Are Secure Defaults Differentiated?” is an interesting question, as it’s one component of a build versus buy framework. For that, I like to reference Sabry Tozin’s, as shared by Roy Rapoport:

Are we solving a problem unique to our company? Are we solving a problem at a scale unique to our company? Is the cost and effort of integrating an off-the-shelf solution so large that we may as well build one? What are the purchasing/ongoing license costs of the product in comparison to building it ourselves?

Reviewing build versus buy has led to this look at buying and selling secure defaults.

The Seller’s Pitch for Secure Defaults

Travis spoke at QCon Plus about “A Big Dashboard of Problems.” I found this talk provides the core pitch for buying secure defaults. To summarize:

1. Many security tools only detect issues, and at best try to remediate a subset

   1. Effectively, this is selling ticket generation

   2. A big red dashboard has diminishing value, thousands of issues are overwhelming, not actionable

2. Dashboards have three issues:

   1. Unsolvable problems

   2. Unactionable findings

   3. Unimportant findings

3. Defaults work due to:

   1. transaction barriers: there is pain in making any change

   2. loss aversion: people are wired to stay with their current settings

   3. discounting and procrastination: people generally put a discount on something that will happen in the future

   4. preference formation: defaults are seen as expert guidance, and inertia forms when you stay in a specific state

Who is Selling Secure Defaults

There are a lot of flavors of secure defaults on the market.

In Application Security, they often take the form of “enterprise-ready products and services”-as-a-service. Take:

• WorkOS: “Start selling to enterprise customers with just a few lines of code” - APIs for authentication and audit logging

• BoxyHQ: “Security building blocks for developers” - APIs for authentication, audit logging, and a “privacy vault”

• Pangea: “Security services for developers” - APIs for authentication, audit logging, embargo enforcement, redaction, etc.

• Arcjet: “Security layer for Node.js apps” - NPM library for rate limiting, bot protection, email verification

In Infrastructure Security, many startups begin by focusing on AWS or Terraform:

• Substrate: "is a CLI tool that helps teams build and operate secure, compliant, isolated AWS infrastructure”

• Delve: “Get HIPAA-compliant in days with automated infrastructure, a step-by-step checklist, and real-time monitoring”

• Gruntwork: “Your new AWS infrastructure as code. Live in days”

• Resourcely: “Standardize and enforce secure infra configuration”

Another common target is secure by default Kubernetes:

• Massdriver: “a visual development platform for deploying best-practice cloud-native architectures with integrated observability and security”

• Loft.sh: “we invented vCluster as virtualization technology that makes it easier and more secure to set up multi-tenant Kubernetes clusters”

Increasingly, there is a focus on supply chain and containers, from companies like Chainguard.

In Endpoint Security, there is a large batch of Enterprise Browser companies, like Menlo Security, Island, and Talon. Application allowlisting is available from companies like Airlock Digital or ThreatLocker.

Challenges in Selling Secure Defaults

The market for secure defaults is definitely kicking off, and we’ve hit the stage where clear challenges are manifesting.

Hard to just sell security

A big takeaway is that even startups trying to sell secure defaults don’t get to stay within that scope for long. This is most obvious in the Infrastructure realm, but applies to application security, and in endpoint security to a lesser extent.

In infrastructure and applications, security is a feature. In the former, you notably end up competing with both the underlying infrastructure providers (who are increasingly striving to make defaults secure) as well as all the “easy ways to run docker in the cloud” successors to Heroku. Companies end up pivoting to more generic platform plays, like Massdriver (which is marketing as a "platform engineering accelerator”), or they shut down like Atomized (YC 20, shut down in 2022). Aptible, for example, started with a strongly security oriented pitch and now positions as a broad “developer platform.”

You also can’t just sell to security, because while getting budget for secure defaults might be possible, implementation is very dependent on broader engineering buy-in and adoption. This need to sell into engineering functions further encourages feature drift aware from pure security.

Secure defaults are cultural and custom

What is “secure” is not always universally consistent. Take encryption - depending on your regulatory and compliance requirements, as well as the specific architecture, you’ll want different defaults. If you’re doing FedRAMP, you’ll want FIPS. If you’re not, FIPS is less secure than alternatives!

Secure by default is also always evolving. For example, AWS has iteratively released new “block public access” features for various services, creating newer safe defaults.

It also depends on your specific culture and business, and how that impacts your risk tolerance. For example, startups or early adopters may want to trade off ergonomics and execution speed with some level of security rigor.

All this risks requiring a Services business to sell secure defaults, which can make the products hard to scale. Take Astra, for example, which pairs a secure “platform-as-a-service” with baked in contracting hours.

Challenging billing and deployment models

On a technical level, there are also complications tied to billing and deployment.

One tension is between self-hosted, hybrid/bring-your-own-cloud, and SaaS/fully managed. There is an increasing support burden the most the customer controls the environment, but often customers are concerned about fully outsourcing the security.

In the application security space, you see a lot of products tied to a vendor API. This has performance, reliability, and trust implications. I think this model is often picked though because it allows for more visibility and control over consumption by the vendors. Many of these technologies could be easily consumed as a local library, but that presents some anxiety around licensing and billing!

Finally, onboarding can be difficult, especially if it involves an existing technology stack migrating to the vendor’s “secure defaults.” This expensive migration is hard to motivate, because the value can be difficult to measure immediately. It also can be hard to show the “wow” moment early in the journey.

Where does this leave us?

1. Ideally, secure-by-default would be a feature of everything, not a bolt-on product category. We’re making progress, but I don’t think we’re all that close.

2. Open-source has a lot to offer, especially for application security, but there are many gaps  - anyone know of an SSRF prevention library for Java?

3. I think there is still room to sell secure defaults in infrastructure, but they should strive to:

   1. Inject opinionated controls into my CSP

   2. Interoperate really well with my existing code base and infrastructure

   3. Be extensible and allow incremental migration

   4. Be designed for usage by engineers day to day, not just security experts

What do you think? Are you currently a customer or prospective customer of secure defaults? What did I miss?