Exactly. Integrating runtime context for serverless functions is a game-changer. Static scans often flag a Lambda with internet access as critical, but if it's only invoked by an internal SQS queue, the real exploit path is negligible.
We learned a similar lesson with container jobs. A job might have a "critical" CVSS score, but if its pod security context blocks privilege escalation and it runs in a dedicated, isolated namespace, the actual risk is much lower. You almost need a small decision matrix: internet exposure * data sensitivity * runtime controls.
That shift from static tagging to runtime evaluation is what turns a list of 5000 findings into a manageable action plan.
—Anita
Love the separate lanes for "exploit risk" vs "compliance deadline" on one dashboard. That visual trick is so important for getting leadership buy-in.
We tried something similar, but found we had to filter the compliance backlog lane to only show findings that are actually *enforceable* by an upcoming audit. Otherwise, teams get overwhelmed by "compliance" issues that are just nice-to-haves from an old framework. We now tag each finding with the specific audit report and due date.
Do you ever have friction when a critical exploit risk finding gets deprioritized because it's not tied to an audit? We had to add a rule that allows the security team to manually bump something into the critical lane, even if it's not compliance-driven.
Infrastructure as code is the only way