Skip to main content

Feedback to the Team on Security Results

🌟 Objective​

To ensure that security test results are delivered to the teams in a clear, contextualised and actionable way, promoting:

  • Technical and functional understanding of the findings;
  • Accountability for fixes and improvements;
  • Integration of security into the team's workflow and culture;
  • Reduced response time and friction between AppSec and Dev.

A finding is only addressed when it is understood, accepted and prioritised by the responsible team.


🔍 What “giving feedback to the team” means​

Giving feedback to the team involves:

  • Making findings available with context and impact, not just tool IDs;
  • Avoiding noise, false positives and redundancies;
  • Communicating in the channels where the team already operates (e.g. PR, backlog, Slack);
  • Establishing mechanisms for continuous improvement and visibility;
  • Fostering ownership and a constructive culture.

💡 Security feedback should be an extension of the quality process, not a parallel channel.


⚙️ How to apply​

  1. Automate the delivery of findings at the team's points of contact:
    • Automatic comments on pull requests (e.g. via Semgrep, SonarQube, GitHub Actions);
    • Contextual alerts (Slack, Teams, IDE notifications);
    • Security dashboards per project or release;
  2. Classify findings by severity and expected action (e.g. “Fix now”, “Accept with justification”);
  3. Include technical and functional context in the communication (e.g. CWE, stack trace, affected code);
  4. Integrate findings in the technical backlog with defined tags and owners;
  5. Hold regular collaborative triage sessions with AppSec and Dev;
  6. Ask the teams for feedback on the clarity and usefulness of the reports.

✅ Good practices​

  • Use inline comments on PRs for SAST findings with clear context;
  • Avoid PDF reports or manual exports - use live, integrated channels;
  • Bring security into sprint review or refinement meetings;
  • Establish tagging conventions in the backlog (e.g. #security, #review-required);
  • Measure the average reaction and resolution time (lead time) per team or type of finding;
  • Celebrate quick fixes, zero regressions and coverage milestones.

📎 Cross-references​

DocumentStrategic relevance
08-gestao-findings.mdEnsures the lifecycle of findings with technical context
Chapter 06 - DevelopmentBrings security closer to agile cycles and code ownership
Chapter 07 - Secure CI/CDFeedback delivery integrated in the pipeline
Chapter 14 - GovernanceManagement and maturity KPIs

🧠 Effective feedback turns findings into decisions. It is in the way risks are communicated that trust and security maturity are built.