69 docs tagged with "rastreabilidade"

Reinforced recommendations for environments with greater regulatory demands or maturity

Advanced governance practices applicable to contexts of high maturity or regulatory requirements

Strategies for annotating security validation decisions and evidence in the code itself or in the development cycle

Decision, validation and minimum evidence criteria for secure architecture, including the architectural baseline model and invalidation conditions

Traceability model between ARC requirements, threats, architectural decisions and auditable evidence, with a matrix template and update criteria

Techniques to generate, sign and validate artefacts with trustworthy provenance, ensuring traceability from build to production.

Canonical catalogue of SbD-ToE application security requirements, organised by technical domain, with applicability by risk level (L1–L3) and minimum acceptance criteria for validation, audit and integration into backlogs.

Formal, cross-cutting and authoritative process for the management of exceptions to security requirements and controls in SbD-ToE

Instrument for binary and auditable verification of the practical adoption of continuous security validation practices.

Method used to validate claims of traceability, maturity and mitigated threats in the SbD-ToE manual

Generation, versioning and use of SBOMs as evidence of composition, not as proof of security

Canonical catalogue of security requirements for containers and images (CNT-001 to CNT-012), with applicability by risk level and acceptance criteria for the selection of base images, hardening, signing, scanning, runtime policies and access to registries.

Essential list of security requirements organised by category and risk level

Canonical catalogue of security requirements for the management of third-party dependencies (DEP-001 to DEP-010), with applicability by risk level and acceptance criteria for SBOM, SCA, library governance and update policies.

Organisational policy that defines the requirements for the controlled use of development support tools, including generative AI assistants (GenAI/Copilot) and autonomous agents with tool-use (A0–A4), with a focus on mandatory review of output, traceability, licence validation, autonomy mandates and the maintenance of human responsibility, proportional to the criticality level (L1, L2, L3).

Prescriptive rules to ensure that security test results are verifiable, reproducible and auditable, with protection of critical assets and separation between automated signal and human decision.

Specifics of exception management in the context of secure development - SAST, linters and code review

Specifics of exception management in the context of the secure architecture requirements (ARC-001..013)

Use of feature toggles with security, traceability and the capacity for reversal in production.

Structures, policies and practices to ensure organisational governance, supplier integration and transparency in the SbD-ToE cycle

Canonical catalogue of organisational security governance requirements (GOV-001 to GOV-017), with applicability by risk level and acceptance criteria for ownership, exceptions, contracting, traceability, continuous validation, maturity, technical onboarding of third parties, access review, coordinated vulnerability disclosure, privileged accounts and identity lifecycle.

Prescription for the controlled use of automated generation tools (including AI) in development, without changing the application requirements

How to apply secure CI/CD practices throughout the application lifecycle, with proportionality by risk, normalised user stories and auditable evidence

Practical integration of governance, exception and contracting practices into the SbD-ToE lifecycle

Integration of requirements practices throughout the phases of the development lifecycle

Integration of threat modelling throughout the development cycle

Rationale and logical structure of the requirements themes used in the catalogue

Canonical catalogue of security requirements for IaC projects (IAC-001 to IAC-013), organised by risk level, with acceptance criteria for the governance of repositories, pipelines, state, modules and configuration drift.

Automated execution of security tests as part of CI/CD pipelines, with traceability and thresholds.

How to integrate threat modelling practices into technical architecture artefacts and approval processes

How to replace the manual threat → requirement mapping using platforms such as IriusRisk, while maintaining traceability with Chapter 2

Technical and process indicators for assessing the coverage, traceability and effective validation of the security requirements applied by risk level, with mapping to the cross-cutting SbD-ToE governance dimensions.

How to link identified threats to the formal requirements defined in Chapter 2

Standardised procedure for the secure onboarding of third parties, with the minimum required training.

Prescriptive practices for the governance, validation and control of reusable modules in IaC, ensuring security, provenance and traceability.

Canonical catalogue of requirements for the security monitoring and operations programme (OPS-001 to OPS-017), with applicability by risk level and acceptance criteria for centralised logging, critical events, retention, SIEM, alerts, response SLA, correlation, integration with the IRP, behavioural detection, effectiveness metrics and continuous operational health signals, backups with tested restore and recovery of the application.

Terms used in Chapter 04 with operational definitions and associated artefacts

Model for the recording and formal justification of security decisions and deliverables

Organisational policy that defines the requirements for the traceability of security practices throughout the application lifecycle, including a compliance repository per application, designation of security owners, periodic validations per SbD-ToE chapter, auditable evidence and an organisational dashboard, proportionate to the criticality level (L1, L2, L3).

Formal policies required to ensure the security, reversibility and traceability of deployments in production.

Case study illustrating the application of requirements throughout the lifecycle

Example of a technical quiz used for knowledge validation in the onboarding process.

Policies that underpin the definition, exception and validation of requirements

Two complementary identification systems - the canonical SbD-ToE catalogue and the project's operational tags - and how to articulate them across the lifecycle.

Mandatory per-project verifications to guarantee the application of the defined requirements

Formal risk acceptance is a fundamental step in the risk management process and must be supported by clear, objective and documented criteria.

Binary, auditable checklist of the adoption of the threat modelling practices of Chapter 03

Organisational policy that defines the requirements for the generation, format, signing, provenance, archiving and retention of SBOMs (Software Bill of Materials) in software, container and IaC builds, proportional to the application's criticality level (L1, L2, L3).

Canonical catalogue of structural and design security requirements (ARC-001 to ARC-013), organised by risk level, with acceptance criteria for architecture reviews, ADRs and technical audits.

Canonical catalogue of security requirements for continuous integration and delivery pipelines (CIC-001 to CIC-010), with applicability by risk level and acceptance criteria for pipeline design, secrets management, runner isolation, artefact integrity and security gates.

Organisational policy that defines the security requirements for the process of deploying software to production, including verification of signed artefacts, separation of environments, progressive rollout strategies, separation between automation and human authorisation, and end-to-end traceability, proportional to the criticality level (L1, L2, L3).

Canonical catalogue of security requirements for the deployment process (DPL-001 to DPL-011), with applicability by risk level and acceptance criteria for formal approval, artefact provenance, automated gates, rollback, deployment credentials, staging, post-deployment monitoring, release gates for agentic systems and end-to-end traceability.

Canonical catalogue of security requirements for the development process (DEV-001 to DEV-009), with applicability by risk level and acceptance criteria for code guidelines, linters, formal review, exception management, provenance and traceable annotations.

Organisational policy that defines the requirements for the formal approval of software releases, including a pre-release security checklist, an automated compliance gate, go/no-go criteria, an immutable decision artefact and end-to-end commit→pipeline→release traceability, proportional to the criticality level (L1, L2, L3).

Process for triaging, prioritising, tracking and resolving vulnerabilities detected in security testing.

Definition, application, validation and traceability of application security requirements by risk level

Organisational policy that defines how security requirements must be selected, documented, traced, validated and maintained throughout the lifecycle of each application, proportionally to its classified risk level.

Complete model for validating the requirements of the SbD-ToE catalogue - principles, methods by requirement type, lifecycle moments and a detailed plan by domain with operational tag, recommended method and expected evidence.

Canonical catalogue of requirements for the security testing programme (TST-001 to TST-010), with applicability by risk level and acceptance criteria for testing strategy, SAST, DAST, findings management, regression, pentesting and auditable evidence.

Operational and institutional metrics that make it possible to assess the effectiveness of training and onboarding.

Formal verification checklist for secure technical onboarding, with a record and validation per role.

Process view of the SbD-ToE — five macro-processes that preserve the continuities between the capabilities prescribed in chapters 01–14, defined in measurable form.

Organisational policy that defines the mandatory nature, methodology, execution triggers, formal approval requirements, traceability and management of threat modelling artefacts throughout the lifecycle of applications classified L2 and L3.

Canonical catalogue of threat modelling requirements (THR-001 to THR-007), with applicability by risk level and acceptance criteria for threat identification, formal disposition, requirement derivation and methodological traceability.

🎯 Objective

Cross-cutting organisational policy that defines the traceability requirements between requirements, controls, validation evidence, build artefacts and operational events, ensuring that the security posture is auditable continuously and in proportion to the application's risk level.

Techniques to ensure traceability of changes, use of tagging and secure version management in IaC.

Model linking SCA findings, SBOM, backlog and releases

Ensure that each pipeline execution and each artefact can be traced back to the associated commit, origin and person responsible.