Skip to main content
Capítulo Operacional

This chapter is considered operational in the Security by Design – Theory of Everything (SbD-ToE) model. Its function is to apply, automate and validate the practices defined in the foundational chapters, ensuring their continuous and measurable execution.

The operational chapters implement the SbD-ToE in specific technical contexts, translating foundational prescriptions into practices of verifiable execution, with objective, traceable and auditable evidence.

Security Testing

Security testing is the turning point between theory and practice.
Requirements may be well defined and controls well designed, but only through continuous and verifiable testing is it possible to demonstrate that they work when faced with real code, complex integrations and evolving threats.

This chapter stands out for providing objective and auditable evidence: it confirms whether the measures prescribed in the previous chapters are effective and whether they withstand the pressure of use in production.
It includes automated techniques (SAST, DAST, fuzzing, IAST) and manual/offensive validations (PenTesting), creating a complementary network of assurances.

👉 In short, security testing is not an optional “phase” - it is the continuous validation mechanism that underpins go/no-go decisions at every commit, build and release.

⚖️ Canonical principles applicable to security testing​

In the context of security testing, the SbD-ToE explicitly assumes that:

  • Tools may detect, prioritise and correlate,
    but do not take final decisions.
  • Automated results do not constitute sufficient evidence on their own.
  • The pass/fail decision, the acceptance of exceptions or of residual risk is always human, assigned to an explicit role.
  • A test only “counts” when it produces verifiable, reproducible and auditable evidence.
  • The testing process itself introduces risks (e.g. exposure of data, credentials, telemetry) that must be explicitly controlled.

The prescriptive rules that operationalise these principles are defined in the file
addon/10-evidencia-reprodutibilidade.md.

🧪 Practical prescription​

Practical application must be understood as a continuous cycle, not as an isolated list of tools:

  • What to do:
    Define a clear strategy, automate whatever is possible, test at different layers (code, runtime, integrations) and complete with offensive validation in critical applications.

  • How to do it (proportional to risk):

    • L1: essential tests (SAST + manual checklist).
    • L2: integrated automated tests (DAST, regressions, gates).
    • L3: advanced tests (systematic fuzzing, IAST, pre-production PenTesting).

  • When to apply:

    • Start of each project (formal strategy).
    • Each commit/PR (SAST).
    • CI/CD builds (SCA, IAST).
    • Staging before go-live (DAST, fuzzing).
    • Each release (gates + formal risk acceptance).
    • Audit and independent validation cycles (PenTesting).

  • Why:
    Because validation is the only way to ensure that security is not a promise but proven reality.
    Tests underpin critical decisions and reduce the time of exposure to vulnerabilities.

Testing and analysis — a distinction that decides where each control lives

Not every security verification is a test. A test confronts observed behaviour with expected behaviour: it has a behavioural oracle — this is the case of SAST, DAST, IAST, fuzzing and PenTesting, which live in this chapter. Composition analysis (SCA, Ch. 05), the scanning of secrets, IaC and container images (Chs. 06 to 09) and the functional validation of security requirements (Ch. 02) operate on a lookup or policy oracle: they confront an inventory with a CVE database, with a rule or with an acceptance criterion. The distinction is not academic — it is what justifies SCA living in the dependencies chapter, and not here. This chapter covers the behavioural oracle; the complete verification of the system is distributed across the respective chapters and consolidated in the cross-cutting verification matrix.

👥 Roles involved​

Responsibility for testing is collective, but each role has explicit responsibilities:

  • Developer → fixes findings and creates verifiable automated regressions.
  • QA → runs DAST, fuzzing and validates acceptance criteria.
  • AppSec Engineer → defines the strategy, tunes rules and manages exceptions and evidence.
  • DevOps / SRE → integrates scanners, gates and artefact preservation in the CI/CD.
  • Product Owner → decides go/no-go and approves documented residual risk.
  • AppSec Engineer → conducts offensive validations and provides independent technical evidence.

👉 These responsibilities are operationalised through user stories in aplicacao-lifecycle.md.

📜 Relevant Organisational Policies​

PolicyMandatory?ApplicationMinimum content
Test Strategy PolicyYesAppSec EngineerVersioned document with Ch. 2 ⇄ tests mapping
SAST in PR PolicyYesDeveloper + DevOps / SREAutomatic execution in PRs, L1–L3 thresholds
DAST and Fuzzing PolicyRecommendedQAAuthenticated DAST, fuzzing on critical endpoints
CI/CD Gates PolicyYesDevOps / SRE + AppSec EngineerFormal criteria, preserved logs, recorded exceptions
Secure Release PolicyYesExecutive Management + AppSec EngineerRelease checklist and documented risk acceptance
Offensive PenTesting PolicyRecommended (L2), Mandatory (L3)AppSec EngineerRisk-based scope, technical reports and retests

In the printed version, consult the Manual's Organisational Policies Annex.

🏁 Conclusion​

Testing is what turns security intentions into real evidence.
It is the mechanism that confirms whether requirements have been implemented, whether gates work and whether the application withstands credible attacks.

In the SbD-ToE, security testing is a continuous process of auditable validation, essential to maintaining technical trust, governance and accountability throughout the entire lifecycle.