SIAS-SDC-01 Secure development lifecycle
- Mandatory
- Yes
- Severity
- High
- Applies
- Conditional — the applicant develops, customizes or deploys as code any software in scope
- SecurityInspect Verified profiles
- None
Control objective
Security is designed into in-scope software from the start, so that weaknesses are prevented rather than discovered late.
Testable requirement
- 1.The applicant must have a documented software development lifecycle for in-scope software, including infrastructure as code and configuration as code, that defines the security activities at each phase: requirements, design, implementation, testing, release and maintenance.
- 2.Security requirements (at least authentication, authorization, input handling, data protection and logging) must be identified for each new feature or significant change and recorded in the work item or design record.
- 3.A threat model or documented design security review must be completed and recorded before release for every significant change. Definition of a significant change: a new internet-facing interface or API; a change to authentication, authorization or session handling; a new flow, store or recipient of Restricted data; a new third-party integration with access to in-scope data; or a major architecture change.
- 4.The applicant must maintain a secure coding standard for the languages and frameworks it uses that references a recognized public source of secure-coding guidance (for example, the OWASP guidance). The standard must be reviewed at least every 12 months.
- 5.Developers and reviewers who work on in-scope software must complete secure development training at least every 12 months (see SIAS-WFS-04).
- 6.Where development is outsourced, requirements 2 to 5 must be required by contract, and the applicant must obtain evidence that they operate (see SIAS-TPR-02).
Applicability and scope
Conditional — the applicant develops, customizes or deploys as code any software in scope. Not-applicable rationale as described in the domain introduction. SecurityInspect Verified profiles: none.
Pass criteria
- 1.The lifecycle documentation covers every phase in requirement 1, including infrastructure as code.
- 2.For 100% of sampled significant changes, security requirements were recorded and a threat model or design security review was completed before release.
- 3.A secure coding standard exists, covers the languages and frameworks in use, and was reviewed within the last 12 months.
- 4.Every approver of changes to in-scope production branches, and at least 95% of all contributors, completed secure development training within the last 12 months.
- 5.Where development is outsourced, contracts require requirements 2 to 5 and the applicant holds evidence that they operate.
Severity
High. Escalation to Critical applies only on the standard escalation triggers in the scoring model (§5.7). A resulting defect, such as an authentication bypass on an internet-facing system, is raised under the SIAS control that covers it (for example, SIAS-APP-03).
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 6.2
- Trust Services Criteria
- CC8.1
- ISO/IEC 27001:2022
- A.8.25, A.8.27
- Theme (SecurityInspect wording)
- security built into software design
SIAS-SDC-02 Pre-release code review and security testing
- Mandatory
- Yes
- Severity
- High
- Applies
- Conditional — the applicant develops, customizes or deploys as code any software in scope
- SecurityInspect Verified profiles
- VP-APP
Control objective
Every change is reviewed by someone other than its author and security-tested before it reaches production, so that security defects are caught before release.
Testable requirement
- 1.Every change to in-scope production code, infrastructure as code or pipeline definitions must be reviewed and approved by at least one qualified person other than its author before it is merged into a branch that deploys to production. The reviewer may be internal or contracted.
- 2.The repository or pipeline must enforce requirement 1 technically (for example, protected branches that require an approving review and block self-approval). The ability to bypass it must be limited to named administrators, and every bypass must be logged, justified and reviewed retrospectively within 5 business days.
- 3.Static application security testing (SAST) and secret detection must run on every change merged into a production branch. Dependency analysis is required by SIAS-SDC-05.
- 4.Each internet-facing in-scope web application or API must undergo dynamic security testing (automated, manual or both) before each major release, as the applicant defines major releases in its lifecycle, and at least once each calendar quarter.
- 5.Security findings from requirements 3 and 4 must be triaged. No change with an open Critical-severity security finding may be released. A change with an open High-severity finding may be released only with a documented risk decision by the security owner (SIAS-GOV-01), and the finding must be fixed within the SIAS-VPM-02 remediation times.
- 6.Review and test records must be kept for at least 12 months.
Applicability and scope
Conditional — the applicant develops, customizes or deploys as code any software in scope. SecurityInspect Verified profiles: VP-APP (limited to the named web application, its APIs and the repositories and pipelines that build and deploy them).
Pass criteria
- 1.Requirement 1 is technically enforced on 100% of production branches of in-scope repositories.
- 2.100% of merges into production branches during the look-back period had an approval from someone other than the author, apart from logged bypasses by named administrators, each justified and reviewed within 5 business days.
- 3.SAST and secret detection ran on 100% of sampled merges.
- 4.Dynamic security testing was performed before each major release and in every calendar quarter of the look-back period for each internet-facing application.
- 5.No sampled release shipped with an open Critical finding, and every sampled release with an open High finding had a risk decision and the finding was fixed within the SIAS-VPM-02 times.
- 6.M4 identifies no Critical or High issue, in a category the applicant's tools are configured to cover, that was missed or left untriaged.
Severity
High. Escalate a finding to Critical on the standard triggers, for example where missing secret detection allowed valid production credentials to be committed to a publicly accessible repository.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 6.2
- Trust Services Criteria
- CC8.1
- ISO/IEC 27001:2022
- A.8.28, A.8.29
- Theme (SecurityInspect wording)
- independent review and testing before release
SIAS-SDC-03 Production change authorization, testing and rollback
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
Changes to production are deliberate, tested, authorized and reversible, so that they do not introduce weaknesses or outages unnoticed.
Testable requirement
- 1.Every change to in-scope production systems must be recorded in a change or deployment record that identifies what changed, who made the change, when, and why. This includes code deployments, infrastructure and network changes, configuration changes made in cloud and SaaS consoles, changes to security settings and database schema changes.
- 2.Each change must be assessed for security and operational impact, tested in proportion to that impact before deployment (in a non-production environment where one exists), and authorized by a person other than the implementer, or deployed through a pipeline that enforces the review required by SIAS-SDC-02.
- 3.Pre-authorized standard changes are allowed only for low-risk, repeatable change types listed in a documented catalog.
- 4.Each change must have a documented rollback or recovery approach proportionate to its risk.
- 5.Emergency changes may be deployed before authorization only under a documented emergency procedure. Each must be reviewed and authorized retrospectively within 5 business days.
- 6.After a security-relevant change is deployed, the applicant must confirm that the intended security settings are in effect.
- 7.The applicant must be able to detect changes made outside the process, for example through cloud activity logs, configuration drift alerts or file-integrity monitoring, and must review what it detects.
Applicability and scope
All scopes. Cannot be marked not applicable. SecurityInspect Verified profiles: none.
Pass criteria
- 1.100% of sampled changes have a record with the elements in requirement 1, an impact assessment, proportionate test evidence, authorization by someone other than the implementer (or pipeline-enforced review), and a rollback approach.
- 2.Every unmatched production event from A2 is explained as authorized under the procedure or was detected and handled by the applicant's own process. No security-relevant change is left unexplained.
- 3.100% of emergency changes were reviewed and authorized within 5 business days.
- 4.Standard changes were used only for change types in the catalog.
- 5.A mechanism for detecting out-of-process changes operated throughout the look-back period, and its detections were reviewed.
Severity
High. Escalate a finding to Critical on the standard triggers, for example where an unauthorized change is found to be evidence of active compromise.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 6.5
- Trust Services Criteria
- CC8.1
- ISO/IEC 27001:2022
- A.8.32
- Theme (SecurityInspect wording)
- authorized, tested and reversible production changes
SIAS-SDC-04 Environment separation and production access
- Mandatory
- No
- Severity
- High
- Applies
- Conditional — the applicant develops, customizes or deploys as code any software in scope
- SecurityInspect Verified profiles
- None
Control objective
Development and testing cannot affect production or expose production data, and developers cannot change production outside controlled paths.
Testable requirement
- 1.Production must be separated from development and test environments, either by separate cloud accounts, subscriptions or projects, or by network and identity boundaries that stop non-production workloads and identities from reaching production resources.
- 2.Restricted data from production must not be used in non-production environments unless it is masked, de-identified or replaced with synthetic data, or unless the non-production environment is protected to the same standard as production and included in the assessment scope.
- 3.Developers must not have standing write or administrative access to production. Access for troubleshooting or emergencies must be approved, logged and time-limited (at most 8 hours per grant).
- 4.Test accounts, test data, debug features and default or test credentials must not be present in production.
- 5.Non-production environments that can be reached from the internet must require authentication.
Applicability and scope
Conditional — the applicant develops, customizes or deploys as code any software in scope. Not-applicable rationale as described in the domain introduction. SecurityInspect Verified profiles: none.
Pass criteria
- 1.All in-scope environments are separated as required by requirement 1.
- 2.No unmasked Restricted data is present in non-production, unless that environment is in scope and meets production controls.
- 3.No developer holds standing write or administrative access to production, and every grant in the look-back period was approved, logged and no longer than 8 hours.
- 4.No test accounts, debug features or default credentials are found in production.
- 5.Every internet-reachable non-production endpoint requires authentication.
Severity
High. Escalate a finding to Critical when an internet-reachable non-production environment exposes Restricted data or credentials to unauthenticated parties or allows authentication bypass.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 6.5
- Trust Services Criteria
- CC8.1
- ISO/IEC 27001:2022
- A.8.31
- Theme (SecurityInspect wording)
- keeping development and production apart
SIAS-SDC-05 Third-party component and dependency management
- Mandatory
- Yes
- Severity
- High
- Applies
- Conditional — the applicant develops, customizes or deploys as code any software in scope
- SecurityInspect Verified profiles
- VP-APP
Control objective
The applicant knows which third-party components its software is built from and promptly fixes components that are vulnerable, malicious or unsupported.
Testable requirement
- 1.For each in-scope application and deployable artifact, the applicant must maintain a machine-readable inventory of third-party components (a software bill of materials, or a comparable listing generated from the build) that includes direct and transitive dependencies, container base images and client-side libraries, with versions.
- 2.The component inventory must be regenerated from the build for every production release.
- 3.Components must be checked automatically against public vulnerability data at least daily. Vulnerabilities in components must be remediated within the SIAS-VPM-02 maximum remediation times, unless a documented analysis, validated by the technical tester, shows that the vulnerable code cannot be reached or exploited in the applicant's use.
- 4.Components must be obtained from sources the applicant has approved (the primary public registry for the language, or an internal mirror), with versions pinned by lockfile or digest.
- 5.Components past their end of support must be handled under SIAS-AST-04.
- 6.The applicant must have a process for adding new components that checks at least their maintenance status, known vulnerabilities and provenance (for example, look-alike package names).
Applicability and scope
Conditional — the applicant develops, customizes or deploys as code any software in scope. Not-applicable rationale as described in the domain introduction. SecurityInspect Verified profiles: VP-APP (limited to the named web application, its APIs and their build artifacts).
Pass criteria
- 1.A component inventory generated from the latest production release exists for 100% of in-scope applications.
- 2.The applicant's inventory includes every direct dependency, and A2 finds no missing component that has a known High or Critical vulnerability.
- 3.No open component vulnerability is older than its SIAS-VPM-02 maximum remediation time, except those covered by a tester-validated non-exploitability analysis.
- 4.100% of in-scope build definitions pin dependencies and resolve them from approved sources.
- 5.Automated vulnerability checks ran at least daily throughout the look-back period.
- 6.Every sampled new component went through the new-component process.
Severity
High. Escalate a finding to Critical when a component of an internet-facing in-scope application has a reachable KEV-listed vulnerability, or when a malicious package is found in a production build (evidence of compromise).
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 6.3
- Trust Services Criteria
- CC7.1, CC8.1
- ISO/IEC 27001:2022
- A.5.21, A.8.28, A.8.30
- Theme (SecurityInspect wording)
- known, current and trusted software components
SIAS-SDC-06 Source code, secret and pipeline integrity
- Mandatory
- No
- Severity
- High
- Applies
- Conditional — the applicant develops, customizes or deploys as code any software in scope
- SecurityInspect Verified profiles
- None
Control objective
Source code, build pipelines and the secrets they use are protected, so that no one can tamper with in-scope software or steal credentials through the development toolchain.
Testable requirement
- 1.Access to in-scope source repositories must go through the applicant's identity provider with multi-factor authentication, follow least privilege, and be reviewed at least quarterly (see SIAS-IAM-04). Administrative rights on repositories and on the source-control organization must be limited to named individuals.
- 2.Secrets (passwords, API keys, private keys and tokens) must not be stored in source code, in configuration committed to repositories, in container images or in pipeline definitions. They must be held in a secret manager or in the pipeline's protected secret store.
- 3.Secret detection must cover repository history as well as new commits. Any secret found must be revoked or rotated within 24 hours if the repository is or was publicly accessible, and otherwise within 1 business day of discovery (the same in SIAS-IAM-06 and SIAS-CRY-03), and the exposure must be assessed as a potential security incident. Removing a secret from history does not replace rotation.
- 4.Pipeline credentials must be limited to the permissions the pipeline needs. Short-lived credentials (for example, workload identity federation) should be used instead of long-lived keys. Changes to pipeline definitions must follow the review in SIAS-SDC-02.
- 5.Third-party pipeline components (actions, plugins and similar) must be pinned to an immutable reference, such as a commit hash or digest, and obtained from approved sources.
- 6.Build runners that handle production credentials must be ephemeral or hardened, and must not run jobs from untrusted forks or external contributors without approval.
- 7.Production artifacts should be signed or have recorded checksums, and deployments should verify them.
Applicability and scope
Conditional — the applicant develops, customizes or deploys as code any software in scope. Not-applicable rationale as described in the domain introduction. SecurityInspect Verified profiles: none.
Pass criteria
- 1.Identity-provider sign-in with multi-factor authentication is enforced for 100% of repository access, administrators are limited to named individuals, and an access review was completed within the last 3 months.
- 2.No valid secret is present in current code, repository history or container images, and every historical secret found has been revoked or rotated.
- 3.Every secret found during the look-back period was revoked or rotated within the deadlines in requirement 3.
- 4.Pipeline credentials are limited to required permissions, and every pipeline definition change was reviewed.
- 5.100% of third-party pipeline components are pinned to immutable references.
- 6.No build runner with access to production credentials runs untrusted code without approval.
Severity
High. Escalate a finding to Critical when a valid production credential or private key is exposed in a publicly accessible repository, image or artifact.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 6.2, 6.5
- Trust Services Criteria
- CC8.1
- ISO/IEC 27001:2022
- A.8.4, A.8.32
- Theme (SecurityInspect wording)
- protecting code, secrets and build pipelines
