Which parts of ISO 27001 A.8.25 secure development Backstage can support
If you must show an auditor that secure development rules are established and applied across new services, Backstage templates can carry those rules into the default path, and the catalog can show where services drift from them. The Git platform, the delivery pipeline and security testing still produce most of the proof, so plan your evidence around those systems from the start. A.8.25, Secure development life cycle, sits in the technological theme of ISO/IEC 27001:2022 Annex A, which holds 34 technological controls in clause 8. Its neighbors A.8.26 (application security requirements), A.8.27 (secure system architecture and engineering principles), A.8.28 (secure coding) and A.8.29 (security testing in development and acceptance) cover requirements, design, coding and testing. Backstage touches the design and build-setup parts of this family and very little of the coding and testing parts.
Be precise about which requirements a template can enforce. A Software Template can scaffold a repository with a pipeline definition, scanning steps, a CODEOWNERS file and a README that points to your secure development standard. Those files only prove the rules were applied if the Git platform also enforces branch protection and required reviews, which the template itself cannot guarantee for repositories created outside it. Ask your platform team to list every path by which a service can reach production without passing through a template, and treat each path as a gap to close or document.
The catalog's role is to show drift. Catalog entities can record the template used, the owner, the repository and the system, and scorecard-style checks can flag components missing a scanning annotation or an owner. Confirm which scorecard or check plugin you plan to use, what it reads, and how often it runs, because those choices determine what evidence exists for a given date. DeployOpen can prepare systems, controls and evidence for the assessment, but it does not issue certificates. Certification bodies accredited under ISO/IEC 17021-1 perform the audit, so agree with your certification body early which records they will sample.
How the A.8.25 requirement and related controls map to Backstage capabilities
This table compares five Annex A secure development controls with the Backstage capabilities that can support them and the configuration each one needs. Read each row as a split: what the portal can hold and enforce, and what still has to come from the Git platform, CI pipeline, scanners or assessor testing. The main takeaway is that Backstage defines and distributes the rules, while the evidence that they were applied usually lives in other systems.
| Control | Backstage capability | Configuration needed | What it does not prove |
|---|---|---|---|
| A.8.25 Secure development life cycle: rules established and applied | Software Templates publish a standard path with pipeline, review and scanning steps; TechDocs holds the written rules | Template skeletons with branch protection and required CI jobs; a TechDocs page that states the rules and their owner; sign-in without guest access so only identified users can scaffold | That repositories created from templates were later kept under those rules, or that teams did not bypass the template |
| A.8.26 Application security requirements | Software Catalog records owner, lifecycle and system for each component, so requirements can be tied to the right application | Required annotations or fields for data classification and owner; catalog ingestion from source control so entries stay current | That requirements were elicited, approved or met for each application; the requirements document and sign-off sit outside Backstage |
| A.8.27 Secure system architecture and engineering principles | TechDocs publishes architecture principles and reference designs; catalog relations show system and API dependencies | Architecture decision records in each component's docs; catalog system and API entities linked to their components | That designs follow the principles; a design review record and its outcome must come from the team's own review process |
| A.8.28 Secure coding | Templates can pre-wire linting, dependency and secret scanning steps into new repositories | Scanner jobs in the template's pipeline; branch rules that block merges when checks fail; scanner version pinning | That code is written securely; scanning reduces some risks but does not replace review, and depends on the Git platform and scanner configuration |
| A.8.29 Security testing in development and acceptance | Templates can include test stages and acceptance gates; scorecards in the catalog can show whether those stages exist in each component | Pipeline stages for security tests; a drift check that reads repository and pipeline state; retained test results linked from the component | That tests were effective or that findings were resolved; test results and acceptance sign-off come from the CI system and the Git platform |
How to configure templates and drift checks for A.8.25 evidence
This sequence turns a written set of secure development rules into template settings, catalog fields and drift checks, so each new or changed component carries evidence that the rules were applied and are still in place during the assessment period.
Agree the secure development rule set
Security and engineering leads agree a short, numbered list of secure development rules, such as mandatory code review before merge, secret scanning, dependency and static analysis scanning, protected default branches and approved pipeline templates. Each rule gets a named owner, a scope (which component types it covers) and the evidence that proves it was applied. The output is a signed rule register that maps each rule to the A.8.25 control and to any related A.8.26 to A.8.29 expectations. Confirm the wording with your auditor before building anything, because the register becomes the test basis.
Map each rule to a template parameter or repository setting
For every rule, record where it is enforced: a template parameter, a fixed template step, a repository setting on the Git platform, or a pipeline definition. Rules that a template cannot set should be marked as Git platform or pipeline controls, with the owning team noted. Confirm with your Git provider and scanner vendors which settings and actions your template can apply through its API token and which need a separate administrator step, since not every provider exposes branch protection or scanner enablement to automation in the same way. The output is a mapping table reviewed by security.
Build the template with scanning and review settings
Engineers add the mapped settings to the Software Template: repository creation with protected branches, required reviewers, CI pipeline files that call the approved scanners, and default ownership fields. Parameters should be limited to choices the rule set allows, so developers cannot switch off scanning. Test the template in a non-production Git organization and confirm that each generated repository matches the mapping table. Whether a given scanner action can be called from the generated pipeline depends on your CI system and licenses, so verify that in your own environment. Done means a test run produces a repository whose settings and pipeline files match the register.
Register the output in the catalog with owner and classification fields
Make sure the template's output includes a catalog descriptor with an owner, a system reference and a classification annotation that records the data sensitivity and the rule set version the component was created under. The catalog then becomes the index that links each component to its repository, pipeline and template version. Confirm how your catalog ingestion discovers new repositories and whether the annotation keys you choose are accepted by your scorecard or check tooling. Done means each test component appears in the catalog with all required fields populated.
Add drift checks and a review cadence
Set up checks that compare the live state of each catalog component against its expected rule settings: branch protection still on, scanner still enabled, pipeline file unchanged from the approved template version, owner still set. Scorecard-style plugins or scheduled scripts can produce these results, but confirm which checks your chosen tooling can run against your Git platform and CI system. Agree a review cadence with security and record who triages failures and how exceptions are approved and expired. Done means a deliberately broken test component is flagged and the exception process is exercised once.
Export evidence for the assessment period
At the end of each review period, export the rule register, template versions in use, the catalog listing of in-scope components, drift check results and recorded exceptions with their approvals. Store these with a timestamp and the template and plugin versions in effect, so an auditor can see both design and operating effectiveness. Confirm with your assessor which formats they accept and how much sampling they will perform. The evidence is complete when a sample component can be traced from the rule, through the template and repository setting, to a passing drift result and a documented review.
What evidence the Backstage setup gives an auditor for A.8.25
A.8.25 is tested through records that show the secure development rules were defined, applied and kept applied over the audit period. The Backstage setup spreads that evidence across Git, the CI platform, the catalog, TechDocs and the portal configuration, so each source needs its own retention and export routine. The auditor tests whether the set is complete for the period, which you should confirm with your assessor before you rely on it.
Template definitions and their history
The software template files, the scaffolder actions they call and the rule set they embed live in version control, and their commit history shows when each secure development rule was added, changed or removed. Export the tagged template versions and the merge records for each period, not only the current state. Check that changes to templates required review by someone outside the author group, because that review is part of the evidence. Ask your assessor whether they want the history in the Git platform or in an exported archive.
Catalog entities with owner and system
Each component created from a template is registered in the software catalog with an owner, a system and a lifecycle value. Those fields show which team is accountable for the rules applied to that software and which system it belongs to. Review ownership on a fixed cycle, because an entity with a departed owner has no one to answer for its secure development controls. Export the catalog entities for the period along with the timestamps of their last change.
Pipeline runs and scan results in CI
The pipelines created from templates run the scanning, testing and approval steps, and the CI platform stores each run with its inputs, outputs and the scan findings. These records show that the security testing rules were executed for each change, not only designed. Confirm the retention period configured in the CI platform, since runs may expire before your audit period ends. Export the run logs and scan reports on a schedule into storage you control.
Branch protection and review settings
Branch protection rules, required reviewers and required status checks are set in the Git platform, and they determine whether a change could reach the default branch without review or passing scans. The template should create these settings, but the Git platform holds the authoritative state. Record the settings at the start and end of the period and after any change. Drift between the template and the live repository is a finding you need to detect and explain.
TechDocs for the written rules
The secure development rules that teams must follow are written as documentation and published through TechDocs, which builds the docs from repository content. Versioned sources give you the rule text as it stood on each date, which supports the requirement to establish the rules. Keep the rendered output and the source commit that produced it for each published version. Confirm with your assessor whether the written rules must be approved by a named role before publication.
Backstage configuration and sign-in resolvers
The Backstage configuration records which identity providers are enabled, how sign-in resolves users to catalog identities, and whether guest access is disabled. Auditors look at these settings because they determine who can change the templates and approve the rules. Store the configuration in version control and export the sign-in logs for the period. Check that every provider resolves to the same identity and that no guest access was available in production.
Why drift checks decide whether the default path stays the default
A software template sets its rules once, at the moment it creates a repository. After that, nothing in the scaffolder stops a team from editing the pipeline file, disabling a secret scanner, adding a bypass to a branch protection rule or moving a service to a different runner. For ISO 27001 A.8.25, the rules you wrote into the template describe the intended secure development process, but the evidence auditors test is what the running services actually do. A template without a drift check proves the default path existed on the day of creation, not that it still applies.
A drift check has to read the state that matters after creation. In practice that means three sources: catalog metadata on each component (owner, lifecycle, tags and any annotations the template added), repository settings from your Git platform (branch protection, required reviewers, merge rules, enabled security features) and pipeline definitions from your CI platform (included templates, required scan jobs, approved runners). Each check needs an API permission on every system it reads, and a plan for what happens when a repository is archived, moved or created outside the template. Confirm with your Git provider and CI platform which of these fields they expose, how often they can be read without rate limits affecting you, and whether pipeline configuration is available in a form you can compare against a baseline.
Scorecard views of this kind come from third-party Backstage plugins, not from the core features listed in the Backstage architecture overview, which covers the Software Catalog, Software Templates and TechDocs. Treat the choice of scorecard plugin as a vetting decision: check its maintenance status, the permissions it requests, whether it stores repository data outside your environment, and whether it supports the Backstage release line you run. Whatever plugin you choose, the drift results become audit evidence only if you keep dated snapshots and a record of who acted on each finding, so the scorecard itself needs a retention and review process.
What Backstage does not cover for secure development
Backstage can make the secure path the default path, but it only sees what is written into templates, catalog entries and pipeline metadata. The gaps below sit outside the portal, and each one needs a named owner and a check before anyone assumes A.8.25 is covered.
The ISMS and the risk-based rule selection
Backstage does not decide which secure development rules apply to your organization. That choice comes from your information security management system, your risk assessment and the scope you set for it. Assign the ISMS owner to approve the rule set and the risk reasoning behind each template control. Confirm that the approved rules are versioned somewhere auditors can read, and that the templates reference that approved version rather than a copy someone edited locally.
Security testing results for A.8.29
A template can require a scanner step, but the findings, the test plans and the tester sign-off live in the scanning and testing tools and the teams that run them. Backstage can link to a report but does not hold its content. The security testing owner should keep test scope, dates and results in a system of record. Before assuming coverage, confirm that every pipeline run retains its scan output and that the link from the catalog entry points to a retained report.
Secure coding in application code
Templates set up a repository, a pipeline and default checks, but they do not review the code a developer writes afterward. Secure coding practice, including input handling, secrets use and dependency choices, is a development lead responsibility backed by training and peer review. Confirm that the engineering lead has defined coding standards for each language the templates produce, and that code review is enforced by branch protection rather than by convention.
Production change approval and deployment records
Backstage can record which repository and pipeline a service uses, but it does not approve a production change or prove who approved it. Approval records belong to the change process and the deployment platform, which hold the timestamps, approvers and rollback history. Assign the change manager to define which changes need approval and which may deploy automatically. Before relying on catalog data as evidence, confirm that deployments write their approval and run identifiers somewhere the auditor can sample.
Scanner accuracy and finding triage
A scorecard that counts open findings says nothing about whether the findings are real, duplicated or suppressed without reason. Accuracy tuning, false-positive handling and severity decisions are a security engineering task performed in each scanning tool. The security engineering owner should document triage rules and exception approval. Before assuming coverage, check that suppressions require a recorded reason and an expiry, and that a scorecard failure opens a tracked item instead of disappearing from view.
Independent audit and certification
Your internal evidence from Backstage prepares you for an assessment, but it does not make you certified. Only an accredited certification body issues an ISO/IEC 27001 certificate after an independent audit, and DeployOpen prepares evidence without issuing audit reports or attestations. Assign the compliance lead to agree the audit scope and sampling with the certification body early. Confirm which evidence the auditor expects in your chosen format, because the certification body, not the portal, decides what is sufficient.
Who owns each secure development rule in the default path
The security team decides what the secure development rules are and whether the default path meets them. Its work sits upstream of any template code: it defines the rule set, sets the minimum scanning, review and pipeline standards, and decides which deviations are acceptable. It also reviews exceptions, because an exception that nobody with security authority has approved is a gap an auditor will find.
- Rule set: a written list of secure development rules, each mapped to A.8.25 and to the related controls A.8.26 through A.8.29, with a named owner and a review date.
- Pipeline standard: the required scanning types, blocking thresholds and review gates that every template must include, written in terms the platform team can implement.
- Exception register: approved deviations with the justification, compensating control, approver and expiry date for each one.
- Review records: evidence that the rule set was reviewed on a schedule and after material changes to the Backstage templates.
- Scope decisions: a record of which applications and repositories fall under the default path and which are outside it.
Check that every rule in the set points to a template behavior or a Git platform setting that can be shown in evidence, and that every exception has an expiry the security team actually enforces.
The platform engineering team builds the mechanism that applies the rules. It writes the software templates, the custom actions they call, and the scorecard or drift checks that run against catalog entities after creation. Its evidence shows that the rules are present in the code path and that the checks run, not only that the policy exists.
- Templates: versioned Software Templates that create repositories with branch protection, the required CI scanning steps and review rules set from the security standard.
- Custom actions: scaffolder actions, with their source and tests, that apply settings the stock actions do not cover.
- Drift checks: scorecard or catalog checks that detect repositories or pipelines that no longer match the template, along with the rule each check implements.
- Change history: the Git history of templates and actions, showing who changed a rule, when, and under which approval.
- Run records: scaffolder task logs that show which template version created each repository.
Confirm which Backstage features your version provides for scorecards and scaffolder logs, and how long those logs are retained in your deployment, because the retention period decides whether the evidence survives an audit window.
Application teams use the templates to start services and then own the findings the default path produces. They do not set the rules, but they are the people who fix failed scans, respond to drift alerts and request exceptions when a rule does not fit their system. Their records show that findings were handled and that deviations were documented before they were accepted.
- Service ownership: each catalog component has a named owner in its descriptor, so every finding has a responsible team.
- Finding responses: tickets or issues that record how each scan or drift finding was resolved, or why it was accepted.
- Exception requests: documented requests to the security team that describe the deviation, the affected component and the compensating control.
- Template choices: a record of which template and version each service was created from, held in the catalog or the Git repository.
- Remediation timing: the dates findings were opened and closed, so the team can show that issues were handled in the time the rule set requires.
Check that each catalog component carries an owner who can actually answer for it, and that exception requests are linked from the component so an auditor can follow them without asking.
What buyers ask before building A.8.25 controls in Backstage
What drives the cost and effort of encoding secure development rules in Backstage templates?
The main driver is how many distinct golden paths you need and how many of your secure development rules can be expressed as code. Each template needs its own scaffolder steps for repository setup, branch protection, scanning pipelines and review rules, and each custom action you write adds build, test and maintenance work. Cost also rises with the number of Git platforms, languages and deployment targets the templates must cover. Ask any provider for a written scope that lists the templates, the rules encoded in each, the custom actions required, and the testing and handover deliverables. The quote should separate one-time design and build work from any recurring retainer for upgrades, template maintenance and continuous checks.
How long does it take to build secure templates and scorecards?
Duration depends on the number of templates, the existing state of your pipeline standards, and how many decisions your security and engineering leaders still need to make. Work usually goes faster when the control rules are already written down and agreed, and slower when teams must first settle what counts as an acceptable scanner, review rule or pipeline gate. Your provider should commit to timelines in the written scope, with milestones tied to template releases and handover. Ask for the sequence of work, the dependencies on your Git platform and CI system, and which steps depend on access your team must grant.
What does the work need from our security and engineering teams?
It needs a named security owner who can state the rules in testable terms, and an engineering owner who understands your repository, CI and deployment conventions. Security must define which scanners, review policies and pipeline standards are required, and what exceptions are allowed and who approves them. Engineering must provide access to the Git platform, the CI system and a test environment, and must review the templates with the teams that will use them. Expect both groups to review drafts during the build, since rules that developers cannot follow in practice will be bypassed.
Can an internal platform team build secure templates without outside help?
Yes, if the team already runs Backstage, understands the Software Templates authoring model, and has security staff who can write the control rules precisely. The harder parts are usually the custom actions that call scanners and the Git platform APIs, testing the templates against real pipeline failures, and keeping the scorecards accurate as tools change. Internal teams often underestimate the work of maintaining templates across upgrades. Assess your team's Backstage and CI skills honestly, and consider a fixed-scope engagement for the initial build and handover while your team keeps ownership of day-to-day changes.
Does running Backstage with secure templates make us compliant with ISO 27001?
No. ISO/IEC 27001 is a management system standard, and the platform only supports evidence for the controls you operate. A.8.25 asks you to establish and apply rules for secure development, so you must still decide the policy, assign responsibilities, run reviews of exceptions, and show that teams follow the rules. Certification is issued by an accredited certification body after an audit, and DeployOpen does not issue audit reports, attestations or certifications. What the templates give you is a consistent default path and records of what was created, which auditors may test alongside your policy and governance records.
How do we keep secure templates current through Backstage upgrades?
Backstage ships a main release line monthly and a next release line weekly, so plan upgrades as routine work rather than rare projects. The documented approach is to move all @backstage packages together with yarn backstage-cli versions:bump, and to use the Backstage Upgrade Helper to see template changes between versions before applying them. Templates and any custom actions must then be retested against your CI and Git platform. Security fixes are backported to releases from the last 6 months where feasible, so staying within that window matters. Confirm with your provider how upgrades and template regression tests are handled under a retainer.
What will a certification body test about our secure development rules?
Certification bodies test whether the rules are defined, approved, applied and reviewed, and whether you can show evidence of that over time. Expect them to sample projects created from the templates and check whether scanning, review and pipeline standards were applied, and to ask how exceptions are approved and recorded. They will also look at how you know the templates match the policy, and how drift is detected and corrected. Ask your auditor which evidence formats they accept before you design the scorecards. Accreditation and audit cycles follow ISO/IEC 17021-1, which requires at least one audit in each calendar year of a three-year cycle.
How DeployOpen scopes and delivers A.8.25 configuration and evidence
DeployOpen starts from your current secure development rules and your Backstage templates, then turns those rules into template steps, pipeline standards and scorecard checks that run on every new service. The output is a configured portal, documented control mapping and an evidence trail your team and your certification body can test. DeployOpen prepares these systems and records for assessment but does not issue audit reports or certifications.
How we scope
- Written scope lists which templates, languages and Git platforms receive secure development rules.
- Scope names the scanning, review and pipeline standards each template must enforce before any build starts.
- Scope defines which scorecard checks run, who owns each rule, and how exceptions are approved and recorded.
How we build
- We add scanning, branch protection and review steps to templates, then test each template end to end in a non-production portal.
- Scorecard checks are configured to detect drift from the template baseline and report it to service owners.
- We document how each Annex A control maps to a template, scorecard result or pipeline record for assessor review.
How we hand over
- You receive template source, scorecard configuration, pipeline standards and a runbook for changing them through Git.
- Documentation explains which evidence comes from Backstage, which comes from the Git platform and which comes from your deployment pipeline.
- Handover includes a walkthrough where your engineers rerun the template tests and review an example evidence export.
How we support
- Ongoing support, upgrades and continuous testing of the templates and scorecards are available as a retainer.
- Retainer work can cover Backstage version upgrades, template updates when your standards change, and periodic drift reviews.
- Ask your certification body early which evidence formats and sampling they expect, and confirm those with us in the written scope.
