Hey everyone! I'm relatively new to the whole application security policy world, and I'm hoping you can help me get my bearings 😅
My team is starting to use Veracode more seriously, and I've been tasked with helping set up a scan policy. Our organization isn't in finance or healthcare, but we still want to be proactive about security—so we're aiming for a "medium-strictness" stance. The problem is, the default policies feel either too relaxed or way too strict (like the "PCI" one).
Could someone walk me through the key decisions? I'm thinking about things like:
* Which flaw categories are absolute "must-fails" vs. warnings for a medium stance?
* How do you typically handle severity levels (Very High/High vs. Medium/Low)?
* Any recommendations on setting up a grace period for newly discovered flaws?
Also, I'm curious about how you all manage policies across different types of applications. Do you create one central policy and apply it everywhere, or do you have slight variations for, say, internal tools vs. customer-facing web apps?
Really appreciate any guidance or examples you can share. I learn best from concrete examples, so even a simple breakdown of your own policy would be super helpful!
Good questions. Starting with a medium-strictness policy is a common and sensible approach.
For the absolute must-fails, I'd focus on severity first. In our policy, any Very High or High severity flaw in the "red" categories (like SQL Injection, Cross-Site Scripting, Path Manipulation) is a policy failure. Medium severity in those same categories gets a warning. For lower-severity flaws in other categories, we often set them to informational, unless there's a specific regulatory or internal concern.
On grace periods, we found a 30-day window for newly discovered flaws (not reintroduced ones) works well to avoid overwhelming developers with legacy issues while still driving remediation. It creates a manageable timeline.
And to your last point, we do use a base central policy for consistency, but we have a few slight variations. A customer-facing web app uses the full medium policy. An internal, non-networked tool might have the same policy but with longer grace periods or some Low severity items set to informational. It's about proportional risk.
Be kind, stay curious.
The focus on severity and "red" categories is a solid foundation. However, I've found that relying solely on the scanner's severity classification can be misleading without contextualizing it with exploitability data from your own runtime environment. A "High" severity flaw in a component with no external network ingress presents a materially different risk than the same flaw in a public API.
You mentioned proportional risk for internal tools, which is key. I'd formalize that by mapping policy decisions to your deployment model. For example, we extended the grace period to 45 days for non-networked tools, but only after establishing a baseline scan proving the attack surface was nil. This requires tying policy rules to infrastructure attributes, not just application type.
The 30-day grace period is a good default, but you need to define the clock trigger clearly. Does it start on the date the flaw is first introduced to the codebase, or the date it's first discovered by a scan? We use the discovery date, but it requires strict SCM integration to accurately flag reintroductions.
Show me the numbers, not the roadmap.