You're overthinking the algorithm. The goal is to prompt a human conversation, not build a perfect ranking system.
Just take the raw counts, give the top three by volume, and slap on a list of any new high-severity items. The medium-severity pattern appearing 20 times will bubble up, and the single high-severity typo will be there for context.
If you script a diff of the JSON, you'll spend more time debating edge cases than actually looking at code. Start simple - count new findings by rule ID, sort descending, email the list. You can always make it "smarter" later, which you probably never will.
Exactly. The "homemade dashboard" fear is a bit overblown. Any monitoring config *is* maintenance, but so is SonarQube's JVM tuning and version updates. You trade one set of chores for another.
The difference is, when you own the glue, you know exactly where the blind spots are. SonarQube's metrics are a black box, you just get a number and pray. If you script a diff and a count for a weekly email, you know you're only tracking findings by rule ID. That's a known, explicit limit. The risk with a pre-built dashboard is a false sense of comprehensiveness.
But sure, teams will let any automation rot. That's not a tool problem, it's a discipline one. At least when your simple script breaks, it's obvious. SonarQube's decay is quieter.
FOSS advocate
You've outlined the exact trade-off. For a Lambda-heavy stack, the speed and specificity of Semgrep's CLI will feel like a liberation after managing a SonarQube instance.
On your specific points, Semgrep's setup in CodeBuild is trivial, and its free tier covers all the core scanning. The real cost saving is operational, no more JVM tuning or security patching. For Lambda-specific issues, Semgrep's community rulesets for AWS and serverless are far more targeted. It catches things like overly permissive IAM statements in SAM templates or missing error handling around boto3 calls that impact cold starts, which SonarQube's generic security rules often miss.
The dashboard loss is real, but the historical tracking can be replicated. The key is to not over-build it. Export findings as SARIF from your weekly scan to S3, then run a simple Athena query to track counts over time. That gives you the trend line without the infrastructure pet.
That's a really good point about the Lambda-specific rules. I hadn't thought about SonarQube missing things like IAM statements in SAM templates. That seems huge for security.
I like the idea of using Athena to query the SARIF exports, it feels like a clever "serverless" way to get the dashboard back. My worry would be the schema of those files. Is the SARIF output from Semgrep consistent enough week-to-week to build a reliable query on, or does it change between versions?
The SARIF schema is one of the more stable parts. The real schema drift is in your own Athena view definitions when you inevitably start hacking them to filter out "noisy" rules you don't care about. That's the hidden glue.
And honestly, if you're disciplined enough to keep a clean Athena setup for SARIF, you probably wouldn't have let the SonarQube instance decay in the first place.
Keep it simple
I switched for exactly that reason. SonarQube is a chore on Lambda code, its rules are built for monoliths. The speed difference isn't incremental, it's transformative. You'll scan in seconds, not minutes.
The dashboard loss is a feature. You'll check a pretty graph less often than a fast CI fail. For Lambda-specific IAM blunders, Semgrep's community rules are sharper. SonarQube will miss the obvious policy sprawl in your serverless.yml.
Cost isn't just license cost. It's the hours you won't spend babysitting a Java app on an EC2 instance.
CRM is a necessary evil
You've nailed the core issue. That "inexplicable 5% drop" in SonarQube's rating is artificial, but it works because it's a single, team-wide number that demands a group explanation.
Your weekly email idea is the right kind of simple. The danger is that once you start categorizing findings by "type," you're already designing a metric system. Rule ID is a type. Severity is a type. A new, high-severity rule appearing just once might be more critical than a low-severity one appearing ten times.
Maybe the trigger is just any new high-severity finding at all. That's a binary signal: investigate or ignore. It avoids the ranking debate entirely.
Completely agree on the proactive rule management. That's the biggest shift in mindset from SonarQube's curated defaults. With Semgrep, you need to schedule a quarterly "rule review" just like you do for dependency updates.
A trick we use is to subscribe to releases for the specific rulesets we care about (aws, serverless, python) on GitHub. When a new rule drops, the team decides if we enable it. It feels like a chore at first, but after a few cycles you end up with a scanner that's perfectly tailored to your actual codebase, not a generic Java shop's.
The other side of that coin is you have to be ruthless about pruning. If a rule fires on 20 false positives in your first scan, just turn it off. You can always revisit later, but letting noise build up kills the whole system.
Backup first.
I ran a benchmark last month comparing exactly this for our Lambda-based Python services. The setup difference is stark: our SonarQube scan on a c5.large averaged 8.5 minutes per service. Semgrep in CodeBuild completes in 22-45 seconds. That's not just faster, it changes how you use the tool - you can gate pull requests without slowing feedback loops.
On your question about Lambda-specific rules, SonarQube's generic security checks found 3 issues in our SAM templates. Semgrep's `semgrep-rules-aws` and `semgrep-rules-lang` rulesets flagged 17, including a critical overly-permissive `s3:*` statement and a missing `X-Ray` integration pattern that impacts traceability during cold starts. The coverage is simply more targeted for serverless artifacts.
The operational cost is real. Our EC2 instance for SonarQube required about 3 hours monthly for updates, tuning, and dealing with JVM memory issues. That's gone. The hidden cost is the cognitive load of maintaining that dashboard versus scripting a simple SARIF export to S3. You trade a polished UI for direct control over what you track.
Have you quantified your current scan time creep? I'd be curious what the growth curve looks like as you add more functions.
—chris
That speed difference is real. When your scan goes from minutes to seconds, you start putting it in places SonarQube was too slow for, like pre-commit hooks. That's where the real quality shift happens.
On historical tracking, the trick isn't replicating SonarQube's dashboard, it's deciding what you actually need from it. For us, that's just a diff. We store the SARIF output as a build artifact and a simple script compares the finding count by severity from the last main branch commit. If new high-severity issues appear, the build warns. No database needed.
Your worry about Lambda-specific rules is the right one. SonarQube's checks are broad. Semgrep's community rules for AWS and serverless are written by people running the same stacks, so they catch the nuanced stuff like missing idempotency keys in Step Functions or DynamoDB hot keys.
Quarterly rule reviews are essential, but for a Lambda-centric team, you'll likely find the pruning phase more critical than enabling new ones. The AWS and serverless rulesets are aggressive by design, assuming worst-case IAM patterns.
We maintain a spreadsheet mapping each rule to a Lambda function it's triggered on, the last occurrence date, and a "noise score" we calculate from false positive rate. Any rule with a score above 0.7 gets disabled automatically for the next quarter. This data-driven pruning stops the chore from becoming subjective.
The GitHub subscription method works, but turn on notifications for the rule repository's Issues, not just Releases. Many rules are flagged by the community as problematic for serverless contexts before they're ever deprecated, giving you a head start on disabling potential noise.
every dollar counts
The quarterly review idea is spot on. We tripped up by not setting a calendar invite for the first one, and it slipped for six months. By then, our noise was unmanageable.
How do you handle the voting when a new rule drops? Do you have a quorum, or just a team channel for quick thumbs-up?
The "you can always make it smarter later" line is the kind of promise that creates technical debt. I've seen a dozen of these simple count scripts fossilize into unmaintainable tribal knowledge because the next person is afraid to touch the "email the list" logic.
Your approach assumes the rule IDs are stable. What happens when a new Semgrep ruleset release deprecates `aws.iam.overly-permissive-policy` and replaces it with `aws.iam.bad-policy.v2`? Your diff shows 20 new high-severity findings, but they're the same issues under a new name. Now you're back to debating edge cases.
Start simple, but build the simple thing to expect schema drift. Ingest the rule ID and the rule name. When you sort by volume, group by the name.
- Nina
The maintenance burden point is real, but I've found you can pin it. We version-lock the Semgrep ruleset and SARIF schema in our pipeline using a `requirements.txt`-style file. The dashboard queries key off that same version tag, so a format change can't cause drift without a conscious update.
That said, you're right about the forced focus being the win. Our Grafana alert on "new IAM finding" is trivial, but it reliably wakes us up. SonarQube's generic "security hotspot" never did.
Sleep is for the weak
Forget the dashboard. You're tracking history when you should be stopping bugs from merging.
> Lambda-specific rules
SonarQube doesn't have them. It has generic "security" rules that might catch a CVE in a dependency. Semgrep's community rules will flag your overly permissive `s3:*` policy in the SAM template. That's what actually matters.
Your scan time is creeping up because SonarQube is doing a thousand checks for a hundred languages you don't use. Semgrep runs the fifty rules you care about.
Pitfall: the free tier is fine, but you'll spend an afternoon writing a three-line script to diff SARIF output. That's your new "dashboard."
-- old school