Thoughts on Security Metrics
Security metrics in themselves are not the worst idea out there. Yes, they are abused a tonne by everyone from vendors and consultants to in-house security teams. But they cause headaches which, in some cases, look like fire drills; everyone who has worked with them knows it.
To understand them better, we need to accept that intuitively we love a single number or a letter grade that sums up the security posture of the application, something we can track to create nice little graphs and bring about the progress or lack of it to executives.
My personal thoughts on them are that they work, keep everyone in line and force a conversation from all stakeholders even though it's usually uninformed.
The drawback with the metrics is usually that they are not defined well. Most providers muddle up the scores by overscoring petty stuff, and you get to see updates to the ranking or new suggestions which fluctuate the score violently enough that it creates an unnecessary panic which disturbs the flow of the security development.
I believe leaders and execs should force the application teams to iterate what exactly is open, who owns it and when it would be closed. Optimally one person should own this data and have a broad security view of the platform; I like them to usually be the security architect. Then a weekly kickoff should be performed, with the relevant owners of the security items led by the security architect, and in this kickoff there should be a consensus on the progress of the items owned.
The kickoff could in principle be tightly coupled to target what increases the security score; this could be a good idea if the security architect has good confidence in the metric or the metric is valued high by the leadership.
After the kickoff, the security architect should send a weekly digest for the consumption of the leadership on what exactly is being done and how this will change the metric. This process, I have seen, increases visibility, reassures confidence in the security development and brings about control over the fluctuations. The semantics of how this rhythm is established is up to the organisation in question, but I believe this will be more of a net positive than a negative.
If your organisation is facing some of the issues I touched upon or is uncomfortable with its security outcomes. Try bringing in a rhythm and consistency to the development. This, in my empirical opinion, works very well.