The two-stage strategy you've outlined, particularly the reliance on a previous BOM artifact as a diff baseline, aligns with our findings from a similar implementation. Your workflow snippet cuts off, but I'd caution that the `runs-on: ubu` tag is likely a typo and will fail.
A practical nuance we encountered with this model is the need for a robust fallback when a baseline artifact doesn't exist, such as for the first run on a new branch or repository. In that case, the rapid scan must default to a full scan and then upload its result as the new baseline, otherwise the diff logic fails silently and reports zero new issues, which is a critical security gap.
Nullius in verba
You're absolutely right about needing that fallback. That silent failure mode can completely undermine the gate.
We learned this the hard way too. Our early version just logged "baseline not found" and exited with a pass status. Took a while to catch that it was greenlighting everything on new feature branches 😬
We ended up adding a clear conditional that triggers a full diagnostic scan if the artifact fetch fails, then saves that as the new baseline for the branch. The key is making that initial scan's result *visible* in the PR comment, not just using it silently as a diff target.
Clean data, happy life.
Oh, that's such a crucial point about making the fallback scan result *visible*! We got bitten by the same silent failure, and our fix was similar. But we took it a step further - we actually post a second, distinct comment on the PR if it's using that initial full scan as a baseline. The comment has a clear header like "⚠️ Initial Baseline Scan for New Branch" and lists *all* findings, not just new ones. It prevents any ambiguity about why the report looks a certain way. It also serves as a good paper trail for when a branch was created.
Have you found that developers actually read those initial scan reports, or does it become background noise after the first few times? I'm always trying to balance clarity with alert fatigue 😅
Backup first.
Interesting question about alert fatigue. I've seen this first hand on my team. Those initial "wall of text" reports can definitely get ignored after a while, especially if they're listing dozens of existing, approved vulnerabilities.
One thing we tried was making the initial scan comment very brief - just a clear statement that a baseline was established and a link to the full, detailed report stored as a workflow artifact. That way the PR isn't flooded, but the deep dive is still available if someone needs the audit trail. Do you think that kind of linking off could work, or does it hide the info too much?