Skip to content
Notifications
Clear all

Thoughts on using QRadar for DevSecOps and monitoring CI/CD pipeline security?

3 Posts
3 Users
0 Reactions
4 Views
(@martech_maverick_alt)
Trusted Member
Joined: 3 months ago
Posts: 40
Topic starter   [#1776]

QRadar for DevSecOps? That's a solution in search of a problem.

You're trying to bolt an enterprise SIEM, built for perimeter telemetry, onto a high-velocity pipeline. The data model is wrong. The ingestion costs for ephemeral container logs alone are punitive. What are you actually trying to measure?
* False positives from build logs drowning out actual pipeline compromise alerts?
* Attributing a security event back to a specific git commit or deployment job?
* Or just checking a compliance box?

I've seen teams spend six months on custom DSM development and parsing rules just to get basic visibility. By then, the pipeline has changed twice. If you're serious, start with the outcome:
* Is it runtime threat detection for your build environment?
* Or audit trail correlation for post-incident forensics?

The tool dictates the workflow. QRadar dictates a slow, expensive one. Prove me wrong. What's your actual use case and expected event volume per day?



   
Quote
(@ci_cd_mechanic_7)
Estimable Member
Joined: 3 months ago
Posts: 108
 

Exactly. The cost is the killer. Even if you solve the data model, you're paying for ingestion and storage of logs for containers that lived 45 seconds. That's insane.

I've only seen it work when security already owned QRadar for everything else and forced the issue. The team built a separate, lightweight pipeline event aggregator that only sent curated alerts upstream. But that's just duct tape.

What's your alternative for the audit trail requirement? That's usually the compliance driver behind these ideas.



   
ReplyQuote
(@night_owl_sre_88)
Eminent Member
Joined: 5 months ago
Posts: 22
 

Agree on the core mismatch. The data model point is critical. You can't query for "which commit introduced this vulnerable library" when QRadar's schema is built around IPs and hostnames that no longer exist.

I've seen a team try this. They ended up with a separate graph database just to store the ephemeral build metadata, then pushed a tiny subset of true security events to the SIEM for the compliance dashboard. The operational overhead was massive.

You asked about volume. We were looking at 10k+ pipeline events per hour. It's not about the raw logs, it's about the relationships between them. That's what QRadar can't do.


null


   
ReplyQuote