Internal developer platform security guardrails
paved-road governance, not platform documentation
Internal developer platforms succeed when the secure choice is the default and the insecure choice requires an explicit, audit-trailed override. Run paved-road security guardrails on a single engagement record so registration, scanner coverage, build provenance, deployment gates, severity recalibration, and exception expiry are queryable rather than scattered across pipelines, scanner tools, ticket systems, and chat threads.
No credit card required. Free plan available forever.
Run the paved road as platform-owned guardrails on the engagement record
Internal developer platforms succeed when the secure choice is the default and the insecure choice requires an explicit, audit-trailed override. They fail when the paved road is a slide deck nobody reads, when CI security checks are configured per repository rather than inherited from the platform, when deployment gates do not read the security verdict from a shared record, and when exceptions are negotiated in chat and forgotten. Internal security teams, platform engineering teams, and AppSec teams pay the cost together when the paved road exists in documentation but not in pipelines: scanner coverage becomes a survey, supply-chain disclosures trigger frantic spreadsheets, and the next audit reads a paved-road policy that nothing in the platform actually enforces.
This is the platform-contract layer. For the per-finding lifecycle that runs inside the paved road, read the SDLC vulnerability handoff workflow. For the scanner integration that produces the findings the platform contracts gate on, read the DevSecOps scanning workflow. For the upstream intake that registers a new application onto the paved road, read the new application security onboarding workflow. For the structured risk acceptance flow the deployment gate reads, read the vulnerability acceptance and exception management workflow. For the asset-to-owner map the paved-road registration depends on, read the asset ownership mapping workflow. The framework guides that mandate platform-owned secure-by-default operating models include the NIST SSDF implementation guide, the SLSA framework explained for build provenance, and the SBOM guide for supply-chain artefacts.
Six paved-road layers and how the guardrail plays out at each one
Internal developer platform guardrails decompose into six layers. Each layer has a healthy posture (the paved road actually enforces a contract) and a default failure (the paved road exists in documentation but not in the platform). The split below is the starting point for a paved-road operating model that internal security teams and platform engineering teams can both run against.
| Layer | Healthy posture | Default failure |
|---|---|---|
| Repository onboarding and asset registration | Every new service repository registers against the platform with a named owning team, a tier classification, and the required scanner coverage before it can ship a release. The internal developer platform records the registration on a workspace engagement so security inherits the asset, the SLA tier, and the owner map at intake rather than discovering them after the first finding lands. The paved road starts at registration so guardrail evidence is reproducible from day one. | New repositories enter the platform without a registration step. SAST runs eventually because somebody added the workflow file, dependency scanning never starts because the manifest lookup was a copy-paste from a sibling project, and the asset enters the security backlog without an owner. The first finding reveals the registration gap and the team rebuilds the intake retroactively in the middle of triage. |
| Pre-commit and CI security checks | The paved road wires SAST, secret scanning, and dependency analysis into the standard pipeline templates the platform team owns. Developers inherit the checks by using the templates rather than authoring per-repo configurations. Findings raised at the pre-commit and CI stages route to the engagement record with the named developer owner, the affected module, and the calibrated severity. The check is one of the platform team contracts rather than a security team imposition. | Each team writes its own CI workflow, the security scanner runs in some pipelines and not others, and the dashboard shows green for repos that never ran the check. Coverage data is not derivable from the platform; it is an annual survey the security team runs by walking the floor. The next supply-chain disclosure forces a hand-built coverage spreadsheet and the gap surfaces in the audit lookback. |
| Build provenance and supply-chain assurance | The paved-road build pipelines emit signed provenance, generate a software bill of materials, and record the build environment as a verifiable artefact alongside the release. The engagement record holds the SBOM reference, the provenance attestation, and the dependency analysis output so the supply-chain disclosure trail is reproducible. SLSA practices live inside the platform contract rather than inside each application backlog. | Some teams generate SBOMs because the engineer who set up the pipeline cared; others do not because nobody centralised the practice. A vulnerability disclosure in a transitive dependency triggers a manual sweep across every repo to find which builds used the affected version. The supply-chain disclosure trail is reconstructed from CI logs that are already cycling out of retention. |
| Deployment guardrails and progressive delivery | The paved-road deployment pipeline gates on the security verdict the engagement record carries. A release candidate with open critical findings under SLA breach holds at a deployment gate rather than shipping under an undocumented exception. Progressive delivery (canary, percentage rollout, feature flag) is wired into the same record so security and platform read the same posture. Exceptions ride on a documented risk acceptance with a named approver and an expiry date. | Deployment proceeds because the pipeline does not read the security record, or because the security record exists in a tool the deployment system does not query. Critical findings ship to production behind feature flags nobody is tracking. The next production incident traces back to a finding that was open and known but never blocked at the deployment gate. |
| Runtime configuration and platform service defaults | Platform service defaults are secure by default: TLS enforced at ingress, secrets managed through the platform secret store, identity and authentication delivered through the standard SDK, network policies set at the namespace level. The paved road reduces the configuration surface developers can mis-set because the secure choice is the default and the insecure choice requires an explicit, audit-trailed override. | The paved road leaves configuration flexibility undefined. Some teams enable the secure defaults; others ship with the inherited template. The next external scan finds an exposed admin path because a flag was not set. The cause is not the team; it is the platform contract that left the defaults ambiguous. |
| Observability, audit logging, and detection content | Platform services emit structured security telemetry, audit events, and authentication signals through the standard logging pipeline by default. Detection content (queries, alerting rules, dashboards) is platform-owned and applies across every service that uses the paved road. Security and platform engineering read the same activity log when a paved-road service produces a finding, an exception, or a deployment-gate hold. | Each team configures its own logging if it remembers. Some services emit auth events, others do not. Detection content is written per-service rather than per-platform-pattern. An incident response that should resolve from a single query takes a week of log archaeology because the logging contract was never paved. |
Six failure modes that quietly break paved-road governance
Paved-road failures rarely look like failures at the moment they happen. They look like convenience: a faster release, a quicker exception, a simpler pipeline, a verbal approval. The cost arrives at the next audit lookback, the next supply-chain disclosure, or the next production incident that traces back to a guardrail the platform was supposed to enforce.
Paved road exists in slides but not in pipelines
A platform team publishes the paved-road documentation as a Confluence page and a slide deck. Teams read it once and then ship whatever they wrote before. The paved road has zero runtime adoption because nothing in the deployment system enforces the contract. The fix is binding the paved road to the pipeline templates, the deployment gate, and the engagement record so the documentation describes a state the platform actually enforces rather than a state nobody opted into.
Coverage is a survey instead of a query
The next supply-chain disclosure asks which services use the affected library. The platform team runs a Slack survey across engineering, collects answers for two weeks, and fills the gap with assumptions. Coverage is not a derivable property of the platform record. The fix is making registration, scanner coverage, dependency manifest, and build provenance live on the engagement so the same question resolves with a query rather than a survey.
Exceptions are negotiated in chat and forgotten
A team blocks at a deployment gate because of an open critical finding. The platform engineer pings the security lead in a Slack channel and gets a verbal "ship it, fix it next sprint." The exception leaves no record and no expiry. Six months later the finding is still open and nobody remembers why the gate did not stop the release. The fix is a structured risk acceptance event on the engagement record with a named approver, an expiry date, and an activity-log entry the audit lookback can query.
Severity drifts when paved-road teams recalibrate
A SAST finding lands at high severity. The platform team recalibrates it down because "the paved road wraps it," but the wrap is conceptual rather than enforced. The recalibration never lands on the engagement record so the audit lookback reads a different severity than the SAST run produced. The fix is requiring severity recalibration to land as a state event with timestamp, user attribution, and the rationale (which paved-road control compensates and how it is enforced) so severity drift is observable rather than forensic.
Detection content is per-service rather than per-platform
Each service team writes its own auth-failure alert, its own privilege-escalation query, its own anomalous-traffic rule. Five teams produce five rules; sixth team produces none. The detection coverage map is heterogeneous and the runbook for the same alert differs across services. The fix is platform-owned detection content that applies across every service that uses the paved-road logging contract so a single rule covers the same threat across the estate and a runbook update reaches every consumer.
Off-road services accumulate without a migration plan
Legacy services, acquired-company services, and bespoke critical workloads opt out of the paved road and the platform team accepts the drift. Two years later half the estate is off-road and the paved-road benefits do not reach the assets that need them most. The fix is treating off-road services as a documented programme: an inventory on the engagement record, a tiered migration plan, a named platform owner per asset, and a quarterly review against the paved-road coverage target.
Six fields every paved-road policy has to record
A defensible paved-road policy is six concrete fields on the engagement record, not an abstract paragraph in a platform engineering handbook. Anything missing from the list below is a known gap in the guardrail discipline rather than a detail that surfaces later as an incident.
Paved-road definition and entry contract
Which platform contracts a service inherits when it joins the paved road (CI templates, deployment pipeline, secret store, logging pipeline, identity SDK, network policy template, scanner coverage, build provenance) and which contracts are mandatory versus optional. The definition is an engagement-record artefact rather than a wiki page so onboarding is reproducible and the contract is queryable.
Tier classification and required guardrail set
The service tier (Tier 0 critical or regulated, Tier 1 customer-facing, Tier 2 internal-only, Tier 3 experimental) determines which guardrails are required, which are optional, and which exceptions are permitted. Tier and required guardrail set live on the engagement so the platform team and the security team read the same classification and the audit lookback can reconstruct why a guardrail did or did not apply.
Scanner coverage requirement per tier
Which scans are required (SAST, dependency analysis, secret scanning, authenticated DAST on staging, external scanning on production), which schedule applies (continuous, weekly, monthly, on demand), and which evidence has to land on the engagement before a release moves through the deployment gate. Without the requirement, scanner coverage is a per-team preference rather than a platform contract.
Severity recalibration rule for paved-road controls
When a paved-road compensating control reduces real-world exposure (mTLS at ingress, secret store rotation, network-policy isolation, runtime sandboxing), the recalibration lands on the engagement record with the named approver, the cited paved-road control, and the timestamp. Recalibration without an enforced compensating control is an exception rather than a recalibration and rides on the risk-acceptance workflow.
Deployment gate and exception path
The verdict the deployment pipeline reads from the engagement record: open critical or high findings under SLA breach, missing required scanner coverage, missing build provenance, missing SBOM. The exception path requires a structured risk acceptance with a named approver, a documented expiry date, and an activity-log event so the gate is auditable rather than negotiable.
Off-road inventory and migration cadence
The list of services that have not adopted the paved road, the named platform owner for each one, the documented reason for the off-road posture, the migration target date or the documented permanent exception, and the quarterly review of off-road coverage against the platform target. Without the inventory, paved-road adoption is reported as a percentage that nobody can derive from the platform record.
Internal developer platform guardrail checklist
At paved-road review (typically quarterly with a monthly pulse) and at every deployment gate, the platform engineering lead, the AppSec lead, and the named release owner walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.
- Every new service registers against the platform with a tier, a named owning team, and the required guardrail set before any release.
- CI pipeline templates wire SAST, dependency analysis, and secret scanning into the standard build so security checks are inherited rather than configured per-repo.
- Build provenance attestations and SBOMs are emitted by the paved-road pipeline and recorded on the engagement record alongside the release.
- The deployment gate reads the security verdict from the engagement record and holds releases with open critical findings under SLA breach unless a structured risk acceptance is on file.
- Platform service defaults (TLS, identity, secrets, network policy, logging) are secure by default; insecure overrides require explicit, audit-trailed approval.
- Severity recalibration based on paved-road compensating controls lands on the engagement record with the named approver, the cited control, and the activity-log entry.
- Risk acceptances and deployment exceptions carry a named approver, a documented expiry date, and an activity-log entry the audit lookback can reconstruct.
- Detection content is platform-owned and applies across every service that uses the paved-road logging contract rather than written per-service.
- Scanner coverage, SBOM coverage, and provenance coverage are queryable from the engagement record rather than collected through annual surveys.
- Off-road services live on a documented inventory with a named platform owner, a migration target date or a documented permanent exception, and a quarterly review.
- Pre-commit and CI security findings route to the named developer owner via the engagement so handoffs are recorded rather than fired into a side channel.
- AI-generated reports include the paved-road coverage trend, the deployment gate hold history, and the exception register for the leadership cadence.
- The activity log export covers ISO 27001 Annex A 8.25 to 8.30, NIST SP 800-218 SSDF practice groups, OWASP SAMM, and CISA Secure by Design pledge goals.
- Quarterly leadership reads paved-road posture from the live engagement record rather than from a hand-built spreadsheet that nobody can reproduce.
How the paved-road guardrails look in SecPortal
Paved-road governance runs on the same feature surfaces the rest of the security programme already uses: the engagement record, the findings record, code scanning, repository connections, authenticated and external scanning, continuous monitoring, AI reporting, and the activity log. The discipline is binding the platform contracts to a single record so coverage, exceptions, deployment-gate verdicts, and audit evidence are derivable from the same surface platform engineering and AppSec already operate against.
Engagement-level paved-road registration
The paved-road definition, tier classification, required guardrail set, scanner coverage requirement, and severity recalibration rule sit on the engagement record. Findings logged against the engagement inherit the policy so guardrail evidence is queryable and reproducible across releases rather than reapplied each cycle.
SAST and dependency analysis on the build
Code scanning runs Semgrep SAST and dependency analysis against repositories connected through GitHub, GitLab, and Bitbucket OAuth. Findings land on the engagement record with the affected module, dependency, or path so the deployment gate reads coverage and severity from the same record the platform team operates against.
DAST against staging and production
Authenticated scanning with AES-256-GCM encrypted credentials hits paths that require login; external scanning covers internet-facing surface. Findings recalibrate severity against runtime exposure and route to the named AppSec triage owner so the paved-road verdict reads against the production reality.
Continuous monitoring schedules
Continuous monitoring schedules (daily, weekly, biweekly, or monthly) keep the paved-road verdict fresh so the deployment gate reads against current scanner coverage rather than against a snapshot from the prior release. Drift between releases lands as state events rather than as runtime alerts.
RBAC for platform and AppSec roles
Team management with owner, admin, member, viewer, and billing roles separates platform engineering ownership of the paved-road contract from AppSec ownership of the verdict and from developer access to inherited findings. Risk acceptance approvals and severity recalibration are gated on the role boundary, and MFA enforcement keeps approver identity defensible.
Activity log as the audit trail
Every paved-road registration, scanner-coverage state change, severity recalibration, deployment-gate hold, risk acceptance, and exception expiry lands on the activity log with timestamp and user attribution. The CSV export is the evidence trail SSDF, ISO 27001, SOC 2, OWASP SAMM, and CISA Secure by Design assessors expect when they ask for the paved-road operating evidence behind the headline coverage number.
Five views the paved-road operating model actually drives
The reports that drive paved-road governance are not the static slide that lands at a quarterly review. They are the live views platform engineering, AppSec, and security leadership read between reviews. The five below are the ones every meaningful paved-road programme settles on, and they all derive from the live engagement record rather than a parallel CI-tool extract or a hand-built coverage spreadsheet.
Coverage by tier and guardrail
Services on the paved road, services off the paved road, scanner coverage by tier, SBOM and provenance coverage by tier. The view that shows whether paved-road adoption is trending up or whether off-road services are accumulating without a migration plan.
Deployment-gate hold history
Releases that held at the deployment gate, the cited reason, the resolution (remediation, risk acceptance, gate override), and the time-to-resolution. The view that distinguishes a working gate from a negotiated one and that surfaces patterns in the kinds of holds the paved road keeps producing.
Exception register and expiry posture
Active risk acceptances, named approvers, expiry dates, compensating controls, and renewal posture. The view that distinguishes time-bound exceptions from drift, surfaces approaching expirations before they go silent, and gives the leadership cadence a defensible exception read.
Severity recalibration trail
Severity recalibrations tied to paved-road compensating controls, with named approver and cited control. The view that catches downward severity drift before the audit lookback reads a different severity profile than the SAST or DAST run produced.
Activity log export
Every paved-road registration, coverage event, severity change, deployment-gate hold, risk acceptance, and exception expiry with timestamp and user attribution. The CSV export is the evidence trail behind the headline paved-road numbers, ready for SSDF, ISO 27001, SOC 2, SAMM, and CISA Secure by Design audit reads.
What auditors expect from paved-road governance
Paved-road evidence shows up in audit reads whenever an external assessor reviews the product security or platform engineering programme. The frameworks below all expect the programme to show that secure development and secure operations are platform-owned, that coverage is queryable, and that exceptions are documented. A documented paved-road policy without enforcement evidence reads as a process gap.
| Framework | What the audit expects |
|---|---|
| NIST SP 800-218 SSDF | PO (Prepare the Organisation), PS (Protect the Software), PW (Produce Well-Secured Software), and RV (Respond to Vulnerabilities) practice groups expect documented evidence that secure development practices are platform-owned, that vulnerabilities are tracked across SDLC stages, and that closures are verified. Paved-road registration, CI scanner coverage, build provenance, and deployment-gate evidence on the engagement record produce the SSDF artefacts assessors read against PO.5, PS.1 to PS.3, PW.4 to PW.9, and RV.1 to RV.3. |
| ISO 27001:2022 | Annex A 8.25 (secure development lifecycle), 8.26 (application security requirements), 8.27 (secure system architecture), 8.28 (secure coding), 8.29 (security testing in development), and 8.30 (outsourced development) expect documented secure-development practices, calibrated severity, named owners, and reproducible verification at each stage gate. The paved-road contract is the operational embodiment of the SDL controls; the engagement record is the verification trail. |
| SOC 2 | Common Criteria CC7.1, CC7.2, CC8.1, and CC9 expect the entity to detect vulnerabilities, respond on a defined timeline, manage changes, and operate vendor management for the components that flow into the build. A paved-road contract running on the engagement record produces the change-management trail and the vulnerability-response trail in one place rather than reconciling across pipelines, scanner tools, and ticket systems. |
| OWASP SAMM | Practices in the Construction (Build, Secure Build, Operational Management) and Verification (Architecture Assessment, Requirements-Driven Testing, Security Testing) business functions expect the programme to show that secure-build patterns, SBOM emission, and security testing are platform-owned and queryable. The paved road moves these practices from project-level to programme-level and the engagement record is the artefact assessors read at each maturity tier. |
| CISA Secure by Design | The pledge expects that customers benefit from default-on hardening rather than opt-in patching. A paved road with secure-by-default platform services (default MFA, default TLS, default secret rotation, default logging, default network isolation) is the operational evidence behind goals 1, 4, and 6 (default MFA, reducing classes of vulnerabilities, CVE completeness) because the paved-road metrics show whether classes of vulnerabilities are being reduced at the platform layer rather than caught on the way out. |
| NIST CSF 2.0 | GOVERN, IDENTIFY, PROTECT, and DETECT subcategories expect a documented operating model, an asset inventory derivable from the platform record, protective configuration defaults, and platform-owned detection content. The paved road is the operating expression of these subcategories at the platform layer, and the engagement record is the evidence behind the GV.PO, ID.AM, PR.PS, PR.IR, and DE.CM subcategory reads. |
Where paved-road governance sits in the wider security programme
Paved-road governance composes with the rest of the security programme on the same engagement record so the platform-contract layer stays connected to the per-finding, per-control, and per-release work that runs alongside it.
Upstream and adjacent
Paved-road governance depends on new application security onboarding for the registration intake, asset criticality scoring for the tier classification, asset ownership mapping for the named owning team, DevSecOps scanning for the SAST and dependency findings the gate reads, and the secret scanning remediation workflow for the credential-leakage lifecycle that runs alongside.
Downstream and reporting
Paved-road evidence rolls into SDLC vulnerability handoff for the per-finding lifecycle inside the contract, vulnerability acceptance and exception management for the structured exception flow the gate reads, control gap remediation for the GRC layer that links findings to framework controls, security leadership reporting for the leadership cadence that reads paved-road posture as a leading indicator, and the audit evidence retention and disposal workflow for the long-tail evidence chain.
Pair the workflow with the long-form guides and the framework references
Paved-road governance is operational; the surrounding guides explain the secure-by-design and supply-chain assurance expectations the contract has to satisfy. Pair this workflow with the NIST SSDF implementation guide for the federal reference model, the SLSA framework explained for build provenance practices, the SBOM guide for supply-chain artefacts, the threat modelling guide for the design discipline that feeds paved-road tier decisions, and the enterprise DevSecOps guide for the wider programme context. The framework references that mandate platform-owned secure-by-default operating models include NIST SP 800-218 SSDF for the practice groups, ISO 27001 for Annex A 8.25 to 8.30 secure development controls, OWASP SAMM for the Construction and Verification practices, CISA Secure by Design for the secure-by-default pledge, and NIST CSF 2.0 for the GOVERN, IDENTIFY, PROTECT, and DETECT outcome subcategories.
Buyer and operator pairing
Internal developer platform security guardrails are the workflow platform engineering teams run as the spine of the paved-road contract, AppSec teams run alongside as the verdict owner, security engineering teams run as the platform-side detection and runtime owners, DevSecOps teams run when scanner outputs flow into the gate, and internal security teams run alongside the rest of vulnerability management. CISOs read paved-road coverage and exception register trends as leading indicators of whether shifting left at the platform layer is reducing classes of vulnerabilities reaching production rather than relocating them into a different queue.
What good paved-road governance feels like
Registration is intake, not retrofit
Every new service registers against the platform with a tier, a named owning team, and a required guardrail set before the first release. The paved road starts at intake so the security record inherits the contract from day one rather than assembling it after the first finding lands.
Coverage is a query, not a survey
Scanner coverage, SBOM coverage, build-provenance coverage, and detection-content coverage are derivable from the engagement record. The next supply-chain disclosure resolves with a query rather than a Slack survey across engineering.
Gates are auditable, not negotiable
The deployment gate reads the security verdict from the engagement record. Holds and exceptions are structured events with named approvers, expiry dates, and compensating controls. Verbal approvals do not survive the audit lookback because they never landed on the record in the first place.
Evidence is derivative of the work
Paved-road coverage trends, deployment-gate hold history, exception register, and severity recalibration trail derive from the live engagement record. The activity log export is the trail and the AI report is the narrative. Nobody assembles paved-road evidence the week before the audit.
Internal developer platform security guardrails are the platform-contract layer between secure-by-design intent and operational reality. Run them on the engagement record so registration is intake rather than retrofit, coverage is a query rather than a survey, deployment gates are auditable rather than negotiable, and the audit lookback resolves from one record rather than from a multi-tool reconciliation sprint. For the per-finding lifecycle that runs inside the paved-road contract, pair this workflow with the SDLC vulnerability handoff workflow; for the structured exception flow the deployment gate reads, pair it with the vulnerability acceptance and exception management workflow; and for the leadership cadence that reads paved-road coverage and gate-hold history as leading indicators, pair it with the security leadership reporting workflow.
Frequently asked questions about internal developer platform security guardrails
What does internal developer platform security guardrails mean?
Internal developer platform security guardrails (sometimes called the paved road or the golden path) are the platform-owned contracts that wire security controls into the standard pipelines, deployment gates, runtime defaults, and observability that developer teams inherit when they ship a service. The guardrails cover repository registration, CI security checks, build provenance and SBOM emission, deployment gates, secure-by-default service configuration, and platform-owned detection content. Done well, the secure choice is the default and the insecure choice requires an explicit, audit-trailed override rather than an unmonitored mis-configuration.
How is paved-road governance different from DevSecOps scanning?
DevSecOps scanning is the integration of security tools (SAST, SCA, secret scanning, DAST) into the development pipeline so findings surface earlier. Paved-road governance is the platform-level contract that decides which scans are required at which tier, which deployment gates the verdict triggers, which compensating controls allow severity recalibration, and which platform defaults apply by default to every service. Scanning produces the findings; the paved road decides what the platform does with them. The two compose. Scanning is the tooling layer; the paved road is the contract layer.
How is paved-road governance different from SDLC vulnerability handoff?
SDLC vulnerability handoff governs how an individual finding transits between SDLC stage gates (design, threat model, SAST, code review, DAST, pre-production, operational handoff) on a single security record. Paved-road governance governs the platform contract every new service inherits when it joins the road and the deployment gate every release reads when it ships. SDLC handoff is the per-finding lifecycle; paved-road governance is the per-service contract. The handoff workflow runs inside the paved-road contract, not alongside it.
Does SecPortal automate the deployment gate?
SecPortal records the security verdict for an engagement (open critical findings under SLA breach, missing required scanner coverage, missing build provenance, missing SBOM, open exceptions and their expiry) on the engagement record so the platform deployment system can read the verdict and decide whether to gate, hold, or proceed. SecPortal does not synchronously create or block CI/CD jobs in third-party systems; the integration runs on the platform side, and the engagement record is the source of the verdict. This keeps the deployment gate auditable rather than negotiated in chat.
How should platform engineering and security split ownership?
Platform engineering owns the paved-road contracts: pipeline templates, deployment gate logic, runtime defaults, secret management, identity SDK, logging pipeline, and detection content. Security owns the verdict the gate reads: scanner coverage requirements, severity calibration rules, exception approval, audit evidence packaging, and framework mapping. The engagement record is the shared surface where the verdict lands and the platform reads it. Done well, the two functions write the contract together and operate the verdict together rather than negotiating each release.
What goes on the off-road inventory?
Each off-road service carries a record on the engagement: the named platform owner, the documented reason (legacy stack, acquired company, bespoke critical workload, regulatory carve-out, intentional experimentation), the tier classification, the migration target date or the documented permanent exception, the compensating controls in place, and the quarterly review status. The activity log captures every promotion of an off-road service to the paved road and every documented permanent exception. The leadership cadence reads paved-road coverage as a target percentage with the off-road inventory as the named gap rather than as an unaccounted residual.
How does AI report generation handle paved-road posture?
AI report generation derives the paved-road narrative from the live engagement record. Coverage by tier, deployment-gate hold history, exception register and expiry posture, off-road inventory and migration progress, severity recalibration trail tied to compensating controls, and SBOM and provenance coverage all land in the report draft as derived narrative. The named approver edits the draft instead of writing from a blank page, and the headline coverage figure always reconciles to the underlying record because the report is generated from the same engagement record the platform team operates against.
How does this relate to CISA Secure by Design and SLSA?
CISA Secure by Design expects the secure choice to be default-on rather than opt-in, which is the operational definition of a paved road. SLSA expects builds to emit signed provenance with a documented build environment, which is one of the paved-road platform contracts. NIST SSDF expects secure-development practices to be programme-owned rather than per-project, which the paved road operationalises. The engagement record is the artefact assessors read for evidence behind each of these mappings, and the activity log is the trail behind the headline.
What about teams that want to opt out of guardrails for a specific release?
Opt-outs ride on the structured risk acceptance workflow rather than as ad hoc decisions. The release owner files the acceptance on the engagement with the named approver, the cited reason, the documented expiry date, and the compensating controls. The deployment gate reads the active risk acceptance and proceeds; the activity log captures the event. At the expiry date, the acceptance closes and the gate restores. Without the structured workflow, opt-outs accumulate in chat and never close, which is the failure mode the paved road exists to remove.
How it works in SecPortal
A streamlined workflow from start to finish.
Register every service against the paved road with a tier and a named owning team
Open the service as an engagement on the workspace. Record the paved-road tier (Tier 0 critical or regulated, Tier 1 customer-facing, Tier 2 internal-only, Tier 3 experimental), the named owning team, the required guardrail set for the tier, the inherited platform contracts (CI templates, deployment pipeline, secret store, logging pipeline, identity SDK, network policy template), and the connected repository so security inherits the asset, the SLA tier, and the owner map at intake. Registration is the contract; the engagement record is the evidence.
Wire SAST, dependency analysis, and secret scanning into the standard pipeline
Connect the repository through GitHub, GitLab, or Bitbucket OAuth and run code scanning with Semgrep SAST and dependency analysis as part of the standard build. Findings raised at the pre-commit and CI stages route to the engagement record with the named developer owner, the affected module or dependency, and the calibrated severity. The check is part of the platform contract rather than a per-team configuration choice.
Emit signed build provenance and a software bill of materials with every release
The paved-road build pipelines emit signed provenance attestations, generate a software bill of materials, and record the build environment alongside the release. Hold the SBOM reference, the provenance attestation, and the dependency analysis output on the engagement record so the supply-chain disclosure trail is queryable rather than reconstructed from CI logs that have already cycled out of retention.
Read the security verdict at the deployment gate from the engagement record
The paved-road deployment pipeline reads the security verdict from the engagement record before promoting a release: open critical or high findings under SLA breach, missing required scanner coverage, missing build provenance, missing SBOM, and active exceptions with named approvers and expiry dates. Releases that fail the verdict hold at the gate rather than ship under an undocumented exception. The verdict is auditable rather than negotiable.
Run severity recalibration and risk acceptance as structured events on the record
When a paved-road compensating control reduces real-world exposure (mTLS at ingress, secret store rotation, network-policy isolation, runtime sandboxing), the recalibration lands on the engagement record with the named approver, the cited paved-road control, and the timestamp. Opt-outs ride on a structured risk acceptance with a named approver, a cited reason, a documented expiry date, and the compensating controls. Verbal approvals do not survive the audit lookback because they never landed on the record.
Operate continuous monitoring and platform-owned detection content
Continuous monitoring schedules (daily, weekly, biweekly, or monthly) keep the paved-road verdict fresh between releases. Authenticated and external scanning cover staging and production. Detection content is platform-owned and applies across every service that uses the paved-road logging contract so a single rule covers the same threat across the estate. Drift between releases lands as state events on the engagement rather than as runtime alerts surprising the on-call.
Maintain the off-road inventory and the migration cadence
Each off-road service carries a record on the engagement: the named platform owner, the documented reason, the tier classification, the migration target date or the documented permanent exception, the compensating controls, and the quarterly review status. The leadership cadence reads paved-road coverage as a target percentage with the off-road inventory as the named gap rather than as an unaccounted residual. The activity log captures every promotion of an off-road service to the paved road and every documented permanent exception.
Features that power this workflow
Orchestrate every security engagement from start to finish
Vulnerability management software that tracks every finding
Find vulnerabilities before they ship
Repository connections for SAST and SCA
Test web apps behind the login
Vulnerability scanning tools that map your attack surface
Monitor continuously catch regressions early
Collaborate across your entire team
Multi-factor authentication on every workspace
AI-powered reports in seconds, not days
Every action recorded across the workspace
Compliance tracking without a full GRC platform
Run paved-road guardrails on one engagement record
Tier classification, scanner coverage, build provenance, deployment gates, severity recalibration, and exception expiry on a single auditable record. Start free.
No credit card required. Free plan available forever.