Security team keeps breaking our CI/CD

>How do you balance security requirements with actually shipping code? It's hard to tell where you are at in the chain of command, but the short answer to your question; managers need to perform a risk analysis of the cost of change vs. no change. It sounds like maybe there have been some deployment issues with these tools so I'll offer a good specific strategy here. Make your metrics your security team's metrics, keep your security team's problem their problem, and use policy/standards/requirements as a weapon. What does that mean here? * Your documented and approved Secure Application Development Lifecycle (Policy/Standard take your pick) has a requirement that all builds by the CI/CD pipeline must complete in less than "n" minutes (< 20 minutes in this case). Any changes that result in a violation of this policy must be approved by (insert manager name no one will bother). Play games with this requirement to your benefit; set a different requirement for the "deploy" portion of the CI/CD pipeline. Security wants to introduce a tool that adds 15 minutes to each development environment build and it causes the build time to violate the Secure Application Development Lifecycle, they - not you - have to get it approved. Someone complains why developer velocity is down after it's approved, pull the impact of build time on developer productivity. Security complains that you've created an arbitrary requirement (hint; this scenario does and, hint, what that led to the tool being implemented is valid) counter by pointing out there is 5 minutes available in the Test environment build or deployment time budget and they can have that time. Why will this not satisfy the control they are trying to introduce? * Never be the blocker and structure all interactions to cost the other side more time then it costs you in time. In this case, offer the solution of scanning in the time available in the Test build budget and ask them to define why this doesn't meet their control. When they point out you're obstructing (hint; you are) simply state you are trying to assist in determining requirements to delivery done and just request again Why will this solution not satisfy the control they are trying to introduce? >Feel like we're optimizing for compliance BS instead of real security. At the risk of generalizing. I believe Real Security(tm) is compliance BS, and that compliance BS is the organization making reasonable efforts to demonstrate due diligence and due care to shift risk (read as "cost") to someone else. Again, at the risk of generalizing, the desired outcome of real security is not to fix all vulnerabilities; it's to construct an impenetrable wall of due care, due diligence, and risk diversion to protect the company …. there not being any vulnerabilities is just a coincidental outcome. This phrasing can't be used in polite company so pretend I just used this phrase; Reasonable Cybersecurity. The counter to any compliance BS is to show the implementation of the proposed control (container scans in this case) cost the organization more then not doing it. >fails if there's a 3-year-old openssl version that's not even exposed. I can't help you on this one, what are doing keeping 3 year old vulnerable dependencies around! There's intentionally no question mark on that statement. Even if you do "prove" it's not exposed, how do you prove it is not exposed in future builds and will never be accidentally exposed in the future builds. The best I can offer is offer to try to scope the security team with rules of engagement - they can only scan the final container image and not the intermediate products. I'd not expect this to be successful.