Automate wherever possible. There’s no replacement for a thorough code review done by a seasoned engineer. But automated scanning tools can complement human reviewers. There are both open source and commercial tools out there for static code analysis, CVE scanning, configuration validation, and policy enforcement.
Set reasonable policies. While development teams can find enforcing automation policies a challenge, it’s important to draw some hard lines around what teams can and can’t do without approval. For example, security teams might want to write policies to prevent the creation of world-readable S3 buckets, or disallow containers running as root in the company’s production Kubernetes cluster.
Have regular security-focused learning sessions. The team needs to know all the ways security flaws crop up. While learning sessions can take away from valuable development time, they’ll help keep security top-of-mind for each of the development engineers. As a part of each session, ask the team to identify relevant parts of the company’s application that’s worth a second look given what they’ve learned.
Give recognition to anyone who points out security concerns. If people don’t feel heard or appreciated when talking about security, they’ll stop speaking up. By acknowledging their concerns and praising their diligence in front of the group, managers will encourage others to adopt a security-focused mindset.
What’s the type of threat? Not all security threats are equal. If there’s a chance an attacker could exfiltrate personal information about the company’s end users, hold the release. But if it’s a denial-of-service on a beta project, it makes sense to ship with a “ToDo” to tighten the code up later on.
How likely is an exploit? This becomes a particularly important question when dealing with security findings from automated scanning tools. Perhaps Trivy has discovered a CVE related to Git in one of the company’s Docker images – if the application never uses Git, the chances of it being exploited are near zero.
What upstream protection does the company have? Some security issues sit far downstream from the first line of defense. For example, if the company runs an application with known vulnerabilities, it probably doesn’t want to expose it to external traffic. But if it’s running behind a firewall and isolated from other parts of the infrastructure, the team may decide it’s a manageable risk; the firewall will keep out any external attackers, and the team can minimize the splash damage of an attack through isolation.