Rethinking GitHub's Security Counter: A Call for Actionable Git Statistics

Rethinking GitHub's Security Counter: A Call for Actionable Git Statistics

In the world of software development, clear and actionable metrics are crucial for maintaining project health and fostering developer productivity. A recent discussion on the GitHub Community platform has brought to light a significant point of friction concerning the 'Security and quality' tab counter, prompting a reevaluation of how these vital git statistics tool are presented.

The Problem with Permanent Records in Actionable Counters

The core of the issue, as raised by user glen-84, lies in the current behavior of the 'Security and quality' tab counter. Since its evolution from a simple 'Security' tab, the counter has become more prominent, yet its underlying logic remains unchanged: it displays the number of published security advisories for a repository. While publishing advisories is a commendable practice for responsible disclosure, these are permanent records of fixed vulnerabilities, not open tasks.

This design creates an inconsistency with other repository navigation counters, such as 'Issues' and 'Pull requests,' which clearly indicate open, actionable items that can be resolved, eventually allowing the counter to drop to zero. In contrast, a published advisory cannot be closed or dismissed, meaning the 'Security and quality' counter can only ever grow. This presents several challenges:

• Disincentive for Maintainers: For project maintainers, a persistent, non-zero counter acts as a 'badge that never goes away,' regardless of how much security work has been diligently completed. This can be a subtle disincentive to publish advisories, even when it's the right thing to do.
• Misleading for Visitors: To a new visitor or an anonymous user, a counter showing '1' (or more) reads as '1 unresolved problem' on a repository that has, in fact, correctly handled and disclosed the vulnerability.
• Impact on KPIs: For a software development manager kpi, this metric can be misleading, potentially misrepresenting the team's ongoing security workload or the project's current vulnerability status.

A Proposal for Actionable Metrics

The suggested solution is straightforward and aligns with the principles of effective git statistics tool: exclude published advisories from the primary tab counter. Instead, the counter should focus exclusively on actionable items that users can address and resolve. Examples include:

• Open Dependabot alerts
• Code scanning alerts
• Secret scanning alerts
• Code quality alerts

By shifting the focus to these dynamic, resolvable items, the counter would behave like its 'Issues' and 'Pull requests' counterparts, reaching zero when all outstanding security and quality work is complete. The full list of published advisories would, of course, remain accessible on the dedicated 'Advisories' page, serving as a comprehensive historical record.

The original post highlighted how the counter is rendered as a simple number, for example, 1 for a repository with a single published advisory and no other findings, visible even to anonymous viewers.

Community's Role in Shaping GitHub

The discussion received an immediate automated response, acknowledging the submission of product feedback. This interaction underscores GitHub's commitment to user-driven improvements, even if individual responses aren't always possible. Such community discussions are vital for refining platform features to better serve the developer ecosystem.

Ultimately, the call is for GitHub to provide more intuitive and actionable git statistics tool. By making the 'Security and quality' counter reflect current, resolvable tasks rather than historical records, GitHub can better encourage responsible security practices, provide clearer insights into project health, and enhance the overall developer experience for millions.