I’ve written two posts about GitHub Advanced Security in the last fortnight, so you’d think I’d be on top of my own alerts. Then I opened the security overview on one of my organisations this week and found a chart I hadn’t looked at in months, with a line that had barely moved. I’d turned the scanning on, felt good about it, and stopped there. The alerts had been piling up politely ever since. Nothing emails you about a number that goes up slowly.
So this is a short one, and it’s mostly a nudge. Go and look at yours.
Where it is#
On github.com, open your organisation and click the Security and quality tab under the organisation name. The page you land on is the overview, and it has three tabs across the top: Detection, Remediation and Prevention. Detection is the default and it’s the one I’d read first. Enterprises get the same thing from the enterprise page.
What mine might as well have said#
I’m not going to share my real numbers, so these are made up. The shape is close enough to be uncomfortable.
| Metric | Value | Change over the period |
|---|---|---|
| Open alerts | 142 | down 4% |
| Critical | 6 | no change |
| High | 41 | down 3 |
| Medium | 78 | down 2 |
| Low | 17 | no change |
| Age of alerts | 203 days | up 11% |
| Reopened alerts | 3 | up from 0 |
| Secrets bypassed | 2 of 9 | - |
The headline looks fine. Open alerts are down 4% and there’s a little green arrow next to it. Read the next row down, though. The average age is 203 days and climbing, which means the alerts being closed are the new ones, and the old ones are just getting older. Six criticals with no change is six criticals nobody has touched.
The docs define Age of alerts as the average age of every alert still open at the end of the period you’ve picked, and a reopened alert is counted from the day it was first created, not the day it came back. So you can’t reset the clock by closing something and letting it reopen. I quite like that.
Reopened alerts only counts alerts that were reopened in the period and are still open at the end of it. Three isn’t many, but each one is something that was marked as dealt with and wasn’t.
Secrets bypassed is the ratio of push protection blocks that someone chose to push through anyway. In my made-up row, push protection stopped nine secrets and two went in regardless. Those two are worth a conversation, and there’s a View details link on the tile that takes you to them.
Below those tiles is Impact analysis, which lists the top 10 repositories and vulnerabilities behind the numbers. If you only have ten minutes, that’s where to spend them, because in my experience most of the total sits in three or four repos.
Getting the list out#
There’s a CSV download on the dashboard if you want to take the data elsewhere. If you’d sooner have a quick list of the worst of it in a terminal, the GitHub CLI will give you every open critical Dependabot alert in an organisation, oldest first:
gh api "/orgs/YOUR-ORG/dependabot/alerts?state=open&severity=critical&sort=created&direction=asc" --paginate \
--jq '.[] | [.created_at[0:10], .repository.full_name, .security_advisory.summary] | @tsv'You should get one line per alert with the date it was raised, the repo and the advisory title. The first few dates are usually the surprising part.
Caveats#
What you see depends on who you are. Organisation owners and security managers get every repository. Everyone else only sees repositories where they already have access to security alerts, so a developer’s dashboard can look far healthier than the owner’s.
It only covers default branches, and archived repositories are left out unless you filter them in. An archived repo with a leaked secret in it is still a leaked secret.
What data turns up depends on what you’ve enabled. Dependabot data is there for any organisation on GitHub Enterprise. Code scanning and secret scanning alerts appear for public repositories, and for private ones where you have Secret Protection or Code Security. I couldn’t confirm from the docs whether organisations on the Team plan get the same dashboard, so if that’s you, click the tab and see. If you don’t have the paid products yet, the 30 day trial I wrote about on Tuesday will fill the charts in.
Final thoughts#
Open Security and quality today, look at the age of alerts figure before anything else, and pick the oldest critical in the Impact analysis list. Fix it or dismiss it with a reason. Then put 15 minutes in the diary once a month to do the same again.
I’m curious how many people do this already. Are you using the security overview, and if you are, do you find it useful, or is it one more dashboard that nobody opens? Let me know in the comments below. I’d like to hear what you look at first.
