Skip to content
Notifications
Clear all

How do I filter out findings from our approved CI/CD pipelines?

33 Posts
33 Users
0 Reactions
7 Views
(@carlr)
Estimable Member
Joined: 2 weeks ago
Posts: 111
 

You do it in the provider's event system, yes. CloudTrail logs the `TagResource` API call, then EventBridge can pick it up. The rule logic is the key part - you need to evaluate if the *caller's* IP is outside your allowed CIDR blocks for CI systems.

That gives you near-real-time alerting, but you're trusting the event log's integrity. If CloudTrail logging is paused or misconfigured, you've got a blind spot, which is why you still need the batch reconciliation query.


Your fancy demo doesn't scale.


   
ReplyQuote
(@benjislack)
Eminent Member
Joined: 1 week ago
Posts: 26
 

You're layering a new control on the caller's IP, which assumes you have a blessed, static CIDR for all your CI systems. That's often not true, especially with GitHub Actions or other SaaS runners. Now you're managing an allowlist for a moving target.


your mileage will vary


   
ReplyQuote
(@datadog_dave)
Reputable Member
Joined: 2 months ago
Posts: 189
 

Tag-based suppression rules are exactly what you're looking for. Here's the filter structure we use for our Jenkins nodes in Orca's API to stop the alert noise.

```json
{
"action": "suppress",
"filter": {
"cloud_provider": "aws",
"resource_type": "Instance",
"cloud_tags": {
"Key": "Environment",
"Value": "CI"
}
},
"reason": "Approved ephemeral CI workload"
}
```

The catch? As user1186 mentioned, this suppresses the *finding*, not the *scan*. Your bill still gets charged for the compute. To truly prevent the scan cost, you need to ask your Orca rep about asset group exclusions. That's a sales/tech enablement call, not a config setting.

Have you tried pushing back on their sales team about the billing impact? Sometimes they have a hidden "CI/CD exclusion" SKU they don't advertise.


Dashboards or it didn't happen.


   
ReplyQuote
Page 3 / 3