A common topic that routinely shows up at security conferences is that of best practices for DevSecOps, with experts telling attendees what they should do.
Tanya Janca, founder and CEO of security training firm We Hack Purple, took a different approach at this week's RSA Conference 2023.
In a keynote address, Janca outlined an exhaustive list of 15 things that she sees DevSecOps groups doing wrong all the time.
"DevSecOps isn't easy. Sometimes it goes wrong, and I want to talk about why," Janca said. "Companies don't want to look bad, they don't want you to know they have vulnerabilities. FYI, you all have some — there is no one that has zero vulnerabilities in production."
15 Things That Go Wrong Over and Over in DevSecOps
1. Breaking builds on false positives
Part of the DevOps process is building applications. However, sometimes introducing security will break the build process, due to identification of a false-positive issue.
"If we're breaking builds on false positives, what we're actually doing is breaking trust," Janca said.
2. Turning on tools without testing them
Janca said that far too often she has seen security teams turn on tools for DevOps pipelines without testing them, which can cause any number of issues.
3. Artificial gates
Part of the DevSecOps process is providing "gates" — points where a pipeline is inspected for compliance with a certain policy. Janca said she has seen security professionals add gates to a process just to slow it down so they can have some form of control. Inevitably what will happen is developers will just go around the gates anyway.
4. Missing test results
Another common issue is that of missing test results. For whatever reason, DevSecOps professionals don't always share all the results with developers building code, which ultimately leads to less security.
5. Runaway tests
Janca noted that she has seen tests implemented by security teams that run for 18 hours or more, while developers' own tests run in a fraction of that amount of time.
"If a test runs a really long time, that derails everyone's work on that team all day," she said.
6. Impossible SLAs
Many organizations are driven by service-level agreements (SLAs), and in some cases those SLAs are impossible for any security or development team to achieve.
7. Untrained staff
Giving staff the responsibility to complete a task without proper training will generally lead to suboptimal results.
8. Bugs lost in the backlog
DevSecOps teams sometimes place discovered bugs in a "backlog," to be addressed at some future point.
"I feel like the backlog is a place where bugs go to die, and they just stay there forever," Janca said.
9. No positive reinforcement
Positive reinforcement and attitude from security teams and leadership are often lacking in DevSecOps.
"Security folks are known for being negative, and we come with bad news," she said.
10. Only worrying about your part
There are a lot of moving pieces with modern development. When DevSecOps pros are only concerned with their own small piece, it doesn't always help move the whole project forward.
11. Multiple bug trackers
Janca said she has often seen security professionals use multiple tools to track bugs, making it difficult for development teams to know where to look for issues.
12. Insecure software development lifecycle
Simply dropping in a tool and saying that's security is not enough to secure the software development lifecycle, which is what Janca has seen many teams do.
13. Overly permissive CI/CD
If everyone has full administrative controls over a CI/CD pipeline, then anyone can disable a test.
14. Automation ONLY in the CI/CD
CI/CD pipelines are typically automated, but there are other areas of development and security that can and should be automated as well.
15. Hiding mistakes and errors
Janca said she has come across teams that hide their mistakes and errors, rather than admitting they have them.
Overall, Janca said that while she knows it's not possible for DevSecOps teams to share everything, it is important whenever possible to turn an error or a mistake into a lesson for the future.
"How can we learn if we never share information?" Janca asked.
About the author
Sean Michael Kerner is an IT consultant, technology enthusiast and tinkerer. He consults to industry and media organizations on technology issues.
