9. Measuring DevSecOps Maturity¶
A mature DevSecOps program is measurable. The quality gates and governance patterns described in earlier sections create signals—metrics that teams can track to demonstrate progress.
Why DORA Metrics Don't Map Cleanly to Salesforce¶
The DORA metrics - deployment frequency, lead time for changes, change failure rate, and mean time to recovery - are the dominant framework for measuring software delivery performance. They are well-validated and widely understood. They are also insufficient as a complete picture for Salesforce DevSecOps.
Deployment frequency on Salesforce is ambiguous without qualification. A team running scratch org-based development may execute dozens of deployments per day while shipping to production once per sprint. A change set-based team may deploy to production weekly but have no automated pipeline at all. Some orgs may deploy immediately after approval (true Continuous Deployment). The raw number means nothing without knowing what is being deployed, to what environment, and through what mechanism.
Change failure rate similarly needs Salesforce-specific interpretation. A deployment that fails at the metadata validation stage before touching any org is categorically different from one that deploys successfully but introduces a regression discovered in production. Salesforce's server-side validation means that many failures are caught pre-commit in a way that traditional software deployments are not - this is a strength of the platform's deployment model, but it means raw change failure rate comparisons against non-Salesforce benchmarks are misleading.
A Salesforce-Specific Metrics Framework¶
Pipeline gate pass rate by stage: The pass rate at each quality gate stage - what percentage of PRs pass static analysis on first run, metadata validation, test execution - tracked over time and segmented by team, component type, and metadata tier. A declining pass rate on static analysis typically signals that developers are not running local analysis, that ruleset changes were introduced without sufficient communication, or that the team is under delivery pressure. Pass rate trends are diagnostic; the raw number at any point in time is less important than the direction of travel.
PR cycle time, segmented by gate outcome: Cycle time from PR opened to PR merged, segmented by whether gates passed on first run or required remediation cycles. The delta between these two cohorts is the cost of rework. A shrinking delta over time is evidence that shift-left feedback investments are having the intended effect.
PR approval time: Time from when an approver was assigned to first response (changes requested or approved) or to final approval. This can indicate if more approvers are needed, or if the current tooling is not surfacing violations in a way that can be handled easily. It can also point to the need for a new quality rule if approvers are spending a lot of time requesting changes when those requests could be automated.
Source-driven deployment ratio: The ratio of deployments that flow through the GitHub Actions pipeline versus those that happen through other means - change sets, Workbench, direct CLI deployments outside the pipeline, or administrator-driven declarative changes. A ratio below 100% means the pipeline is not a true control boundary. Tracking this ratio and driving it toward 100% is the foundational governance metric.
Metadata drift frequency and resolution time: How often drift occurs, how significant it is, and how long it takes to resolve. Drift frequency is a measure of process discipline. A frequency that plateaus rather than declining typically indicates a specific category of change that has not yet been brought into the source-driven model.
Security finding trends: The trend lines for new Critical and High severity findings introduced per sprint, and the time from finding introduction to remediation. Segmenting findings by engine reveals which parts of the stack carry the most risk.
Test suite health: More informative than aggregate coverage percentage are: the ratio of test classes with meaningful assertions versus those that exist solely to satisfy the coverage threshold; the distribution of coverage across classes rather than the aggregate; the trend in Jest component coverage over time; and the frequency with which scheduled full-org test runs surface failures not caught by PR-time test execution. CodeCov (codecov.io) provides longitudinal coverage trend analysis as a complement to GitHub's native Code Scanning, surfacing coverage regressions relative to the base branch and providing historical visibility into which components are systematically under-tested.
Maturity as a Progression, Not a Checklist¶
DevSecOps maturity in a Salesforce engineering organization advances along a recognizable trajectory, but not in clean discrete stages. Teams progress unevenly - strong on static analysis governance, weak on drift detection; excellent test coverage in Apex, no Jest tests at all; rigorous PR gate enforcement, no audit trail instrumentation. The metrics above are useful precisely because they reveal this unevenness and help architects prioritize where investment will have the highest impact.
The earliest stage is characterized by the absence of automation: deployments are manual or change set-driven, quality checks are performed inconsistently, and the concept of a quality gate as a merge prerequisite does not exist. The source-driven deployment ratio metric is the most important single number at this stage.
As basic pipeline automation is established, the focus shifts to gate reliability and developer trust. Developers who do not trust the pipeline - who see it as slow, noisy, or producing false positives - will find ways around it. The PR cycle time segmentation and gate pass rate metrics are the primary diagnostic tools at this stage.
As gate reliability improves, the focus moves to coverage completeness: are all change surfaces instrumented, including declarative metadata and Flow governance? Is the source-driven deployment ratio genuinely at or near 100%?
The most mature organizations treat the pipeline itself as a product - with its own change management process, its own metrics, and its own continuous improvement cycle. Configuration repository changes go through the same rigor as application code. Security finding trends inform developer education programs. The audit trail is actively used for incident investigation.
Observability - GitHub-Native Instrumentation¶
GitHub Actions usage metrics provide aggregate data on workflow run durations, success rates, and runner utilization. A workflow that consistently ran in eight minutes and now takes twenty is either doing more work or encountering a systematic inefficiency.
GitHub Code Scanning aggregates all SARIF-format findings into a unified security dashboard, queryable by severity, rule, file, and introduction date. This is the primary interface for tracking security finding trends across the repository.
GitHub Deployments API records structured deployment events for every pipeline-mediated deployment, providing a clean timeline of what was deployed to which environment and when.
GitHub Actions job summaries ($GITHUB_STEP_SUMMARY) produce per-run structured output that persists beyond the log retention window. For scheduled workflows, job summaries are the primary human-readable artifact of the run.
GitHub Insights - available at the organization level - provides cross-repository visibility into PR cycle times, code frequency, and contributor activity.
For organizations with existing observability infrastructure, GitHub Actions integrates with external platforms via workflow steps that forward telemetry on each run. Datadog, Splunk, Grafana, New Relic, and AWS CloudWatch all have well-supported GitHub Actions integrations that can receive deployment events, workflow metrics, and custom pipeline telemetry - enabling Salesforce pipeline data to be correlated with org performance metrics, incident timelines, and broader engineering analytics. The appropriate integration depends on the organization's existing tooling landscape and is outside the scope of this whitepaper.