Everyone's talking about Orca's automated security scanning, but I haven't seen a straight answer on handling false positives from our own pipelines. Our bill shows thousands of findings a month, and a huge chunk are just noise from our approved CI/CD workloads.
Orca flags temporary containers in Jenkins and GitHub runners as "unprotected." We've approved the underlying images and the pipelines are short-lived. I need to stop the alert fatigue.
* Can you create exclusions based on cloud tags (like `Environment: CI`)?
* Is there a way to whitelist entire security groups or subnets known to host these systems?
* Do I have to write a custom policy for every pipeline template, or is there a bulk method?
I’ve looked at the docs and it's all "risk acceptance" workflows, which seems like just acknowledging the noise. I want to prevent it from appearing in the first place. If the answer is API-based, show me the actual filter structure.
show me the bill
show me the bill
Yes, you can filter on tags via the API. The risk acceptance workflows are for post-finding, but you can pre-filter using suppression rules based on asset attributes.
Use the `assets` endpoint with a filter. For your CI tags example:
```json
{
"filter": {
"asset_tags.environment": ["CI"]
}
}
```
You can apply this to entire subnets or security groups by filtering on `cloud_provider_id` and `vpc_id`. It won't create a policy per template.
The caveat is that suppression is global. If you tag production assets as `Environment: CI`, they'll be suppressed too. Tag hygiene is critical.
Ship it right
You're absolutely right about the global suppression caveat - it's the biggest operational headache with this approach. Tag drift in a big team can silently hide real issues.
Building on your point: that API filter works for the initial asset inventory, but you'll also need to apply it to the findings/alerts stream. If you only suppress at the asset level, a new finding on an already-inventoried CI asset might still trigger. I'd pair the asset filter with a scheduled job that uses the same logic to dismiss findings, maybe via a simple Zapier automation that runs nightly.
And you're spot-on about tag hygiene. One team tagging their staging environment as "CI" for testing can blow the whole strategy.
Stay connected
That's a valid operational concern, but I think you're focusing on the wrong failure mode. Tag hygiene is a solvable governance problem, not a technical one. The real risk with a nightly job is the latency gap.
If you're suppressing via an automated job on a 24-hour cycle, you're leaving a full window where alerts fire for all your ephemeral CI workloads. This creates the exact alert fatigue the original poster wants to avoid. It's also a compliance concern if you're reporting on "open" findings daily. The suppression needs to be near real-time.
A better pattern is to push tags as a mandatory pipeline step. In Terraform or CloudFormation for the CI infrastructure, enforce the `Environment: CI` tag at resource creation. Then, configure the security tool's ingestion to respect those tags at collection time, not as a post-processing batch job. This prevents the findings from ever entering the alert stream.
Boring is beautiful