Discussion: Transition from Security Quality Gates to Continuous Security Assessment

[scherersebastian]

The objective of this issue is to discuss the possible transition from relying on Security Quality Gates (QGs) to adopting a more continuous approach for security assessments. This change aims to make security a continuous process rather than a one-time gate, better aligning with the dynamic nature of security risks and challenges.

While Security Quality Gates have served as a mechanism to ensure a minimum security standard before production, they also possess limitations. The most notable limitation is their 'point-in-time' nature; they are unable to account for the continuously evolving threat landscape, such as newly discovered vulnerabilities in dependencies.

Rationale for Change

• Continuous Security: Security is an ongoing process and cannot be guaranteed by a one-time check.
• Dynamic Threat Landscape: New vulnerabilities may appear in dependencies, even without changes in the project code.
• Developer Responsibility: Enabling developer teams to continuously assess and manage security findings promotes ownership and faster remediation.

Proposed Approach

Instead of a single Security Quality Gate, we propose:

• Regular Security Scanning: Weekly or bi-weekly automated scans, with findings to be reviewed by the responsible developer team.
• Peer Reviews: Incorporate security as a mandatory point of discussion during code reviews.
• Security Team Support: The Security Team is available for questions or necessary guidance at all times. They can be integrated into the developer workflow through issue assignments, PR reviews, and participation in forums like the DevSecOps Hour.

Request for Comments

• Do you agree with the move from Security QGs to a more continuous approach? Why or why not?

[scherersebastian]

Also, no security TRGs.

[scherersebastian]

Memento mori

[Essenbreis]

I like this approach. We as a security Team do a step back and the responsibility is with the product teams to contact us. Let's discuss on our WS :-)

[DnlZF]

Workshop discussion and results:

• Write a Security Code of Conduct (-> Include developer resposibility and personal obligation to follow the specified security rules within the TRGs)

[pablosec]

It may also be interesting to have some kind of due diligence process to enable future users of the software (who in the most cases wouldn't have access to the security tab in GitHub) to make sure that the security requirements are implemented.

[scherersebastian]

Workshop discussion and results:

* Write a Security Code of Conduct (-> Include developer resposibility and personal obligation to follow the specified security rules within the TRGs)

There are no security TRGs. Do you want to create even more TRGs?

[scherersebastian]

It may also be interesting to have some kind of due diligence process to enable future users of the software (who in the most cases wouldn't have access to the security tab in GitHub) to make sure that the security requirements are implemented.

@pablosec sounds interesting, please elaborate.

[RoKrish14]

Security TRG 8.0 coming soon for Security