Hi everyone. I’ve been reading up on Veracode for our team, and I keep seeing this "shift everywhere" concept in their material. Honestly, it feels a bit overwhelming, like another layer of process to worry about.
In my world, we’re just starting to get a handle on "shift left" with some basic SAST in our CI/CD for Python ETL scripts. The idea of also shifting right, and everywhere in between, seems like it could create a lot of noise and slow things down. My big fear is adding a ton of gates or checks that could break our production data pipelines over what might be a low-severity finding in a utility script.
For those of you using it, how does this actually work in practice? Specifically:
- Do you have different policies for different parts of your data stack? Like, is a finding in an Airflow DAG treated differently than one in a core analytics library?
- How do you manage the volume of findings without getting paralyzed? Is there a way to sensibly prioritize?
I’m trying to figure out if this is a genuinely useful framework or if it’s just a buzzword that makes security reviews more complicated than they need to be. Any practical advice on making it, well, practical would be really appreciated.
I hear you, that "shift everywhere" messaging can definitely feel like buzzword bingo. We had similar concerns when our security team pushed for it.
Your point about different policies for different parts of the stack is key. You can't treat an Airflow DAG the same as a core library. We set up different severity thresholds for different repos and pipeline stages. For example, a high-severity finding blocks a merge on our main API service, but for a low-risk ETL script, it might just generate a ticket for the next sprint. It's all about configuring the gates sensibly.
The noise is real. We had to spend a lot of time tuning out irrelevant findings (like in third-party vendored code) and focusing on net-new issues. Without that, you just get alert fatigue. Start small - get your "shift left" solid, then maybe add runtime checks (shift right) for your most critical services first. Doing it all at once is a recipe for burnout.
Latency is the enemy, but consistency is the goal.
You're right to be skeptical about new layers. The core idea behind "shift everywhere" is continuous verification, not just adding more gates.
For us, the practical difference between "shift left" and "everywhere" is where the findings *go*. "Left" findings block the developer. "Right" findings from production monitoring feed back into the same policy engine to automatically adjust severity or create tickets. It prevents that exact scenario where a low-severity finding in a utility script would break a pipeline - the system learns it's never triggered in runtime and downgrades its priority.
The prioritization problem is real. We treat it like a triage system:
- Critical/High in core services: block.
- Medium/Low in ETL or DAGs: create Jira ticket, no block.
- Findings in vendored code: suppress after one review.
Without this automation, it's just "shift left" with more reporting points, which is indeed just buzzwordy process bloat.
benchmark or bust