Skip to main content

Security Findings Management

🌟 Objective​

To establish an effective and continuous process for managing security findings - that is, test results that indicate potential vulnerabilities or bad practices, ensuring:

  • Triage by criticality, context and reproducibility;
  • Integration with the backlog and development tools;
  • Centralised consolidation for prioritisation and traceability;
  • Validated handling by owners with organisational memory;
  • Reduction of noise and redundancy between validation tools.

⚠️ Ignored or scattered findings weaken security. Centralised and tracked findings strengthen it.

🔍 What security findings are​

Findings can result from:

  • SAST, DAST, IAST, fuzzing;
  • Manual tests or reviews;
  • SBOM/SCA tools or organisational policies;
  • Runtime monitoring or production alerts.

Each finding represents a risk observation that requires a decision:

  • Is it true? Is it a false positive?
  • Has it been accepted, mitigated or resolved?
  • Is it associated with a requirement, release, commit?
  • Has it been validated or merely hidden?

💡 Findings ≠ CVEs: they are concrete occurrences in the context of the application and must be treated as such.

⚙️ How to apply​

  1. Centralise all findings in a consolidated system (e.g. DefectDojo, Jira with plugins, Vulcan, Security Hub);
  2. Create objective triage criteria (e.g. CWE, OWASP Top 10, organisational risk);
  3. Associate each finding with traceable metadata: commit, version, module, requirement;
  4. Integrate findings in the team's backlog with a defined status and SLA;
  5. Establish a formal flow: triaged → accepted → fixed → validated;
  6. Consolidate data from multiple tools with correlation of duplicates and false positives.

🔐 Centralisation makes it possible to prioritise resources, ensure a response proportional to risk and generate executive visibility.

✅ Good practices​

  • Use platforms such as DefectDojo, Vulcan, Security Hub or integrated solutions for centralisation;
  • Classify findings by risk (L1–L3) and adjust the process:
    • L1: findings may be triaged directly in the backlog;
    • L2–L3: must be centralised, auditable and followed up by AppSec;
  • Avoid duplication between tools - establish correlation pipelines;
  • Automate the export of findings to triage boards and KPIs;
  • Review accepted findings every quarter;
  • Integrate dashboards by release, module, team or type of flaw.

📎 Cross-references​

DocumentStrategic relevance
Chapter 02 - RequirementsValidates requirements and enables traceability to the requirement
Chapter 06 - DevelopmentFindings evidence recurring flaws or violation of secure patterns
Chapter 07 - Secure CI/CDFindings originating in continuous validation jobs
01-sast.md, 02-dast.mdProduce findings that must be triaged
09-feedback-equipa.mdDefines communication mechanisms and ownership
Ch. 14 - addon/12-processo-excecoes.mdFindings not resolved within the TST-003 SLA require a formal exception through this process

📊 Findings management is a continuous process, not an export file. Its centralisation and rationalisation by risk are the foundation for informed and effective security decisions.