Secure-by-default Certification for proactive Security Engagement

The traditional security model is often reactive—reviewing applications after they’re built. While effective at catching issues, it often slows engineering and struggles to keep up with the pace of innovation. Secure-by-default certification is a security assurance framework that shifts security earlier in the lifecycle.Instead of auditing individual applications after the fact, this program proactively pre-certifies foundational, reusable engineering templates and modules. This fundamental shift eliminates entire classes of security defects before a developer even writes a line of code—dramatically reducing friction between security and engineering.

At Salesforce, this shift to secure-by-default certification is an important and growing part of how we are evolving our security development practices, with adoption expanding over time across common engineering foundations. Over the past three years, implementing secure-by-default certification at scale has prevented nearly 300,000 security defects introduced through commonly used infrastructure templates, helped teams avoid over 690,000 security risks, and saved an estimated two million developer hours by eliminating the need for repeated, manual security rework. While Salesforce continues to expand its use of secure-by-default certification, these results reflect the compounding impact of applying this principle into shared infrastructure. 

This article shares practical lessons, challenges, and key takeaways from building and implementing secure-by-default certification at scale. The intent is to share actionable guidance for security professionals to move security decisions earlier into design and implementation, reduce avoidable defects, and make security easier to adopt as part of everyday engineering workflows.

The Evergreen Security Challenge: Integrating Security Without Slowing Development

In today’s fast-moving software development environments, organizations are under constant pressure to ship features quickly—often at the expense of security. Despite increased investment in security tools and awareness programs, many vulnerabilities are still identified late in the software development lifecycle (SDLC). This delay not only increases the cost and complexity of remediation but also exposes systems to potential risks in the interim.

To address these challenges, organizations have invested in shifting security left—bringing security checks earlier in the development lifecycle. This includes introducing automated code scanning during development (i.e., as code is written in the IDE) and in CI/CD pipelines during build and deploy phases. These scans can issue warnings or block builds when misconfigurations or insecure patterns are detected. Some teams refer to the more assertive forms of these checks—those that actively prevent deployments or enforce remediation—as security guardrails. 

While IDE linters and security plugins offer early warnings, their non-blocking nature often leads to developers addressing security concerns only when enforced later in the CI/CD pipeline by security guardrails. This late-stage intervention causes friction and delays due to the need for reactive fixes or architectural changes. Consequently, developers must revisit seemingly completed code. As is well known, the later a defect is caught in the SDLC, the more expensive and disruptive it is to fix.

Additionally, code or resource scanning—while effective—has limitations. Their detection logic is bound by the capabilities of the scanning tools and the scope of rules defined. They often miss issues tied to business logic, contextual decisions, or architecture-level risks. In this environment, “shifting left” still doesn’t always mean “shifting early enough.”

Most coding defects are found after the coding phase, which increases the cost to fix.

Secure-by-default Templates: Less Rework for Developers, More Confidence for Security

The core challenge lies in integrating security without compromising development velocity. To address this, the secure-by-default certification focuses on proactive integration of security into reusable code templates—an increasingly common development practice in large organizations. These reusable code components, often owned by Developer Productivity teams, serve as foundational building blocks—from Infrastructure-as-Code (IaC) modules to full-stack application frameworks. Because they’re widely adopted across teams, they present a powerful opportunity for security teams to scale their impact.

The secure-by-default certification process embeds not just baseline security controls, but also company-specific policies and proactive security enhancements—far beyond what code scanning tools or CI/CD guardrails typically enforce. For example, while guardrails might detect that secrets need rotation, a secure-by-default certified template can automate that rotation entirely. Similarly, where scanning tools may flag the need for log storage, a secure-by-default certified template can go further by configuring automated log forwarding to the company SIEM. These built-in safeguards reduce the operational burden on developers, leading to faster release cycles while strengthening security by default.

By certifying these reusable templates, security shifts left into the design phase, reducing the number of defects introduced during coding. Developers benefit from secure foundations without having to decipher or manually integrate complex security requirements. In return, security reviewers spend less time chasing gaps in implementations—especially when they know the foundation is already certified. Some organizations may even adopt fast-track reviews for applications built on secure-by-default certified components.

Reusable templates and security reference architectures (SRAs) complement each other: SRAs offer secure high-level design patterns, while templates bring them to life through pre-hardened, production-ready code. Used together, they enable scalable, secure-by-default development across the organization.

And importantly, measuring impact becomes straightforward—just track template adoption to see how often your certified, secure building blocks are being used across the company.

Secure-by-default Certification: 5-Step Framework

STEP 1: Discover Developer Productivity Templates

The first step in the secure-by-default certification process is identifying reusable code templates managed by developer productivity teams. These teams often maintain centralized repositories of shared infrastructure and application templates to reduce duplication and improve engineering efficiency.

During this process, you may find—as we did at Salesforce—that templates for certain use cases don’t yet exist. It can be tempting for security teams to step in and build them, but here are two important considerations from our experience. First, maintaining production-grade code templates requires significant engineering effort. Given the limited number of security professionals with software development expertise, our focus should be on scaling security practices—not owning engineering deliverables. Second, decisions about creating reusable templates should align with broader company strategy. A template that promotes a non-strategic technology choice can create long-term friction, even if it solves a security problem. In most cases, Engineering—not Security—is best equipped to make such architectural decisions.

STEP 2: Assess Secure-by-default Requirements

Once reusable templates are identified, the next phase is to perform a comprehensive security assessment. Secure-by-default requirements should combine both industry best practices and company-specific security policies. Importantly, these requirements must address not only mandatory controls but also recommended security enhancements that elevate the baseline.

Unlike standard guardrails, which typically enforce minimal compliance, secure-by-default configurations aim for a higher bar. For example, a secure-by-default certified template might require automatic secret rotation rather than leaving it as a manual developer task. Or it may mandate forwarding cloud logs to a centralized SIEM instead of relying on local log storage.

Because secure templates evolve over time, secure-by-default assessments should be conducted on a recurring basis. To scale efficiently and avoid resource bottlenecks, it’s essential to automate these reviews early—using tools like custom OPA policies or other automated validation frameworks.

STEP 3: Remediate Security Findings

Remediating identified security requirements is the most time-intensive part of the secure-by-default certification process. All code changes must be thoroughly tested before being merged into the template repository—after all, these updates will eventually run in production. Certification is only complete once all security requirements have been implemented and verified.

As you work through these changes, consider tagging the code to track which production resources are using certified secure-by-default templates. At Salesforce, this tagging has been crucial for maintaining the secure-by-default certification program and served as one of the most impactful metrics we shared with leadership.

Although remediation can be challenging, it’s also an opportunity. Collaborating with engineering teams on these fixes builds trust and strengthens the relationship between Security and Development—positioning Security as an enabler, not a blocker.

STEP 4: Map Security Controls to Company Standards

While not directly part of coding secure-by-default templates, mapping secure-by-default requirements to company security standards provides long-term value. At Salesforce, we generate secure-by-default metadata in every certified code repository—JSON files that link certification review reports and explicitly map the default security controls to the company’s security policies.

This mapping offers two key benefits:

1. Developer Productivity teams can more easily track and promote security-certified templates to their consumers.
2. Security Review teams can automate assessments for applications built with certified templates. secure-by-default certified templates represent a comprehensive set of controls aligned with company standards. While many controls are enabled by default, some are left configurable to maintain flexibility. If Security Review teams could automatically detect overridden elective controls, they could quickly determine an application’s compliance status. This form of metadata-driven evidence is a foundational step toward automating design reviews and compliance assessments.

STEP 5: Maintain Secure-by-default Library and Measure Impact

To promote adoption, maintain a centralized, easily accessible library of secure-by-default templates. Ensure high visibility by placing it in locations commonly used by developers and introducing it to key stakeholders, such as Security Review teams and Security Champions.

To measure the effectiveness of your secure-by-default certification program, consider building a metrics dashboard that tracks secure resource adoption, vulnerabilities prevented, and developer hours saved. At Salesforce, we use an automated tool to estimate the time and effort saved for each certified template and display these insights in a dashboard for Leadership. These metrics are based on the assumption that addressing security issues or integrating controls manually would require a measurable amount of developer time. A sample dashboard is provided below:

Sample Dashboard for the secure-by-default certification program

Concluding Thoughts

As security engineers, we have a unique opportunity to make security easier and more scalable for developers. While left-shifted tools like code scanning and CI/CD guardrails help detect and block misconfigurations earlier, they still often require reactive fixes that interrupt developer flow. A more proactive approach—embedding security into reusable, secure-by-default templates—can prevent entire classes of issues before they occur. This reduces misconfigurations, minimizes rework, and saves significant time and effort across teams.

Importantly, secure-by-default certification also helps demonstrate clear return on investment —a challenge for many security initiatives. By tracking metrics like bugs prevented and developer hours saved, teams can show tangible business value, gaining greater leadership buy-in and promoting broader adoption.

By integrating security into the building blocks of software delivery, we enable developers to move faster and more securely. Security becomes a natural part of development, not a disruption—turning security into a force multiplier rather than a gate.