Security Testing Strategy across the Lifecycle

🌟 Objective

To establish an integrated and proportional strategy for applying security testing throughout the software development lifecycle (SDLC), ensuring that:

• The right tests are applied at the right time;
• The depth and frequency of testing are aligned with the application's risk;
• Teams understand the purpose and complementarity of each type of test;
• The strategy can evolve with the organisation's maturity.

An effective strategy avoids both false confidence (an excess of tools without real coverage) and a validation deficit (untested assumptions).

---

🔍 What a security testing strategy is

A security testing strategy defines:

• When to test (e.g. by SDLC phase: coding, build, staging, production);
• What to test (e.g. source code, binaries, APIs, business flows);
• How to test (e.g. static, dynamic, interactive, fuzzing, manual);
• Who is responsible for interpreting results and responding;
• How often (e.g. continuously, per release, by risk);
• Acceptance criteria and minimum thresholds per type of test.

---

🧬 SDLC → Testing Mapping

SDLC phase	Recommended test types	Main objective
Planning	Threat modelling, requirements review	Prevention and coverage
Development	Linters, SAST, IAST	Early detection in code
Build/CI	SAST, SCA, regression tests, SBOM generation	Continuous validation
Staging/Testing	DAST, Fuzzing, IAST, manual validation	Assessment of real behaviour
Production/Operation	Monitoring, sample-based validation, pentest	Post-deploy verification

---

🛠️ How to apply in practice

1. Classify the application's risk (L1–L2–L3) according to Chapter 01;
2. Select the appropriate test types for the risk level:
   • L1: Linters + SAST + basic manual tests;
   • L2: Addition of DAST, security regression, IAST;
   • L3: Full pipeline with fuzzing, coverage per API type, differential tests;
3. Integrate tests in the pipeline with gates, thresholds and traceable artefacts;
4. Document the testing strategy in the repository/project (e.g. a SECURITY-TESTS.md file);
5. Regularly assess the effectiveness of the tests based on real findings and incidents.

---

✅ Good practices

• Apply shift-left testing whenever possible (e.g. SAST on the PR);
• Define clear approval criteria (e.g. minimum coverage, 0 critical findings);
• Adopt risk vs test-type matrices for each repository or product;
• Review the strategy periodically with the AppSec team;
• Include feedback from the tests in the backlog and in continuous improvement processes.

---

📎 Cross-references

Document	Strategic relevance
01-sast.md	Essential part of the start of the strategy
02-dast.md	Dynamic validation - depends on the context
06-cobertura-e-priorizacao.md	Defines the targets and depth of the tests
07-integracao-pipeline.md	Where and how to connect the strategy to CI/CD
Chapter 01 - Risk Management	Defines the application's criticality level
Chapter 02 - Requirements	Defines what must be tested (REQs)
Chapter 06 - Development	Defines the secure practices to be validated
Chapter 07 - Secure CI/CD	Defines how the tests integrate into delivery
Chapter 12 - Monitoring and Operations	Post-deploy observation and runtime validation

---

🧠 A security testing strategy is not a list of tools - it is a decision about how, when and how deeply to validate the security of what is being built. It is the direct reflection of the risk the organisation accepts.