We've been running our main monolith through Veracode for a while now, and the backlog is... daunting. The issue is that a significant portion of the findings are in legacy modules that are considered "stable." The business has explicitly said no refactoring or major changes there due to risk and cost.
Our current approach feels messy. We mark them as "Mitigated - Acceptable Risk" with a comment, but it's manual and our security team pushes back, wanting concrete compensating controls. I'm curious how others handle this.
What's your workflow for these "untouchable" findings? Specifically:
* How do you justify and document the risk acceptance in a way that satisfies security and audit?
* Do you implement any compensating controls at the infrastructure or network layer? For example, if it's a vulnerability in a legacy service, do you wrap it with stricter WAF rules?
* Have you automated any of this? We're thinking of using the Veracode APIs to auto-close certain findings from specific paths with a standard comment, but that feels dangerous.
Here's a snippet of the Terraform we use to enforce a WAF rule for a specific vulnerable endpoint we can't fix in the code, as an example of a compensating control:
```hcl
resource "aws_wafv2_web_acl_rule" "block_legacy_endpoint" {
name = "block-legacy-sensitive-endpoint"
priority = 10
web_acl_arn = aws_wafv2_web_acl.main.arn
action {
block {}
}
statement {
byte_match_statement {
field_to_match {
uri_path {}
}
positional_constraint = "STARTS_WITH"
search_string = "/legacy/v1/sensitive_operation"
text_transformation {
priority = 0
type = "NONE"
}
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "block-legacy-endpoint"
sampled_requests_enabled = true
}
}
```
Is this a valid path, or are we just papering over the cracks? Looking for practical patterns from teams who've been through this.
-- Amy
Cloud cost nerd. No, I don't use Reserved Instances.
I've seen teams use a formal risk register tied to specific findings. It helps with the audit trail, but it's still paperwork. The WAF example is interesting - we tried that for an old API, but the false positives were a nightmare to tune.
Have you gotten pushback from the business about the performance impact of those WAF rules? That was our blocker.
Interesting about the risk register. We use a similar system, but it's only accepted if we tie it to a compensating control. The WAF false positives are a real issue though.
Has anyone tried using a more targeted network policy instead of a full WAF? I'm wondering if segmenting that legacy API from external traffic entirely would be seen as a valid control.
Marking findings as "Mitigated" without actual mitigation is a policy violation on most platforms. Your security team is right to push back. That's just hiding the ticket.
You need a formal risk acceptance process, separate from the tool. Use the API to pull findings into a risk register system, then manage the acceptance there. The finding stays open in Veracode as a true reflection of the code state, which is correct.
Automating the closure you described is dangerous and defeats the purpose of the scan. It makes your audit trail a lie.
Beep boop. Show me the data.