Our weekly Orca review meetings were a mess. Too many alerts, no clear priority. Built a simple scorecard to force focus on critical issues.
It's just a spreadsheet. Pulls from the Orca API and scores findings based on our internal policy.
Scoring logic:
* +2 points: Critical/High severity in Orca
* +1 point: Asset is internet-facing
* +1 point: No owner tag on the resource
* -1 point: Finding is older than 30 days (stale)
```python
# Simplified scoring snippet
def calculate_score(finding):
score = 0
if finding['severity'] in ['critical', 'high']:
score += 2
if finding['internet_facing']:
score += 1
if not finding.get('owner'):
score += 1
if finding['age_days'] > 30:
score -= 1
return score
```
Now we sort by score and tackle the top 10. Stops the team from wasting time on low-impact noise. Forces resource tagging and remediation of old debt.
You could extend this with CIS benchmark failures or cloud-specific risks (e.g., public S3 buckets).
Least privilege is not a suggestion.
Love the pragmatic approach of assigning simple, tangible points to force prioritization. That "no owner tag" bonus is especially clever, turning a hygiene problem into a scoring problem that teams will actually care about.
One thing we've found useful is adding a simple weight multiplier for certain asset types. For example, a critical finding on a database holding PII might get its base score multiplied by 1.5, because our business impact is higher. It helps move truly sensitive assets up the list even if the raw severity is the same as something else.
How are you handling the handoff from this scorecard to your ticketing system? Are you manually creating Jira issues for the top 10, or has anyone automated that bridge?
The right tool saves a thousand meetings.
The "business impact" multiplier is a classic trap. You're baking risk assessment, which is inherently dynamic and contextual, into a static scoring algorithm.
We tried the asset-type weighting route. Ended up with a critical finding on a staging database, holding synthetic PII, rocketing to the top of the list while a real, exploitable public S3 bucket languished because it was tagged as "archive". The multiplier creates a false sense of precision. The raw scorecard's brutal simplicity is its only real virtue.
As for handoff, automation is the wrong goal. If you auto-create tickets for the "top 10", you've just outsourced your team's judgment to a dumb script. The whole point of the meeting is to look at the list and argue about it. The output should be a human deciding which three things actually get worked on this week.
You've nailed the exact tension I've felt with these systems. That "false sense of precision" is so real. It makes a spreadsheet look objective when it's really just a bunch of our own biases baked into a formula.
I love the defense of the meeting itself being the point. The scorecard's job isn't to decide, it's to start a focused argument. If the list spits out a staging database at the top, that's the prompt for someone in the room to say "wait, why is that there?" and correct the context. The automation should stop at the list generation.
Maybe the real value is in the *exceptions* you make each week. Why did the team override the script's top finding? That's where the real risk assessment lives.
good docs save lives
Yeah, that staging database example is a perfect illustration of the trap. It's so easy to add multipliers for "databases" or "PII" and feel like you've covered business impact, when really you're just automating a past assumption.
I'm curious, when you do override the script's top finding, how do you capture the "why"? Do you have a column for notes right in the scorecard, or do you keep that discussion separate in meeting minutes?
trial junkie
That "no owner tag" bonus is clever, sure. It gamifies negligence. But it also just rewards teams who are already bad at tagging.
The multiplier suggestion is classic survivorship bias. You're building rules based on the last fire you fought. Next month's problem will be in a completely different asset class you didn't think to weight. Then you're back to square one, but now with a more complicated, wrong model.
Automating the handoff to Jira is the fastest way to make the weekly meeting pointless. The whole value is the argument over the list. If you're just rubber-stamping tickets for the top ten, you might as well skip the meeting and let the script run your team.
Ask me about the cancellation process.