arthead - stock.adobe.com
DevSecOps, the practice of collaboratively developing secure applications with contributions from software developers, IT security pros and operations teams, is the professed ideal for most enterprises. And, yet, the more things change in cybersecurity, the more they stay the same.
Take leaked secrets, for example. Security and DevOps experts have preached for the last 10 years that developers should not store secrets -- sensitive information such as passwords and other identifying credentials -- in source code. Yet, an analysis by security vendor GitGuardian found 2 million secrets stored in public Git repositories in 2020 alone, according to a presentation at a GitLab virtual event this week.
"A lot of it comes down to human error and a misunderstanding of the dangers of Git," said Mackenzie Jackson, developer advocate at GitGuardian, in an online Q&A during his presentation.
Developers still commonly store and manage secrets in Git because their repositories are private, without considering they may, eventually, be made public, such as when code is donated to open source.
It's also easy to accidentally make code public that's meant to be private, Jackson said. Often, developers use the same Git usernames for personal and work-related projects and can get the two confused.
Another common problem is past versions of code linger in Git repositories -- something many developers aren't aware of, Jackson said. Secrets can also lurk in logs and other automatically generated files without developers knowing.
Finally, even though developers know what not to do, they may not know what they should do instead, one event attendee pointed out in an online chat during Jackson's talk.
"When following blog posts, tutorials, guides ... they all mention that you should never commit your secrets [in code]," the attendee said. "But they almost never tell you where to actually put those secrets."
Jackson shared a link to a GitGuardian blog post about how developers can properly manage secrets. In an interview, he said the response to the blog post demonstrates how common a problem this is.
"It generated more traffic in two days than the rest of the year combined, which proves that there isn't enough information around this out there," Jackson said.
We're all in this together
Secrets management isn't the only area of DevSecOps that suffers from a lack of industry consensus, other GitLab event presenters said. The Open Web Application Security Project's list of top 10 web application vulnerabilities hasn't changed drastically in the last 17 years, for example.
Meanwhile, configuration errors were the leading cause of security issues for the last four years in service provider Cobalt.io's annual penetration testing report, according to a company executive's presentation at the GitLab event.
"Security isn't something we can think about in a vacuum," said Caroline Wong, Cobalt's chief security strategist, in her presentation. "It's not a technology problem. ... It requires people and process innovation."
Wong compared DevSecOps tools development to the development of vaccines for COVID-19.
"What happens when effective vaccines are created? The technical issues are solved, but does the problem just disappear? Of course not," she said. "In some ways, it might be easier to develop a completely new vaccine than it is to do procurement and distribution and communication and actually get people vaccinated."
Just as some lawmakers are now proposing COVID-19 vaccine mandates, some IT industry leaders say DevSecOps needs stronger enforcement.
Many of the major cybersecurity frameworks and regulations, such as the Payment Card Industry's Data Security Standard do not specify best practices for secure code development -- they say only that it must be done, according to a presentation this week by Johnathan Hunt, vice president of information security at GitLab.
"We've tried creativity and flexibility for years," Hunt said in his presentation. "But if it's just a suggestion, then it's more like a hobby -- it competes for your time ... and secure software development becomes subjective, on a personal level."
Organizations such as the National Institute for Standards and Technology, regulators and tech industry experts should get together to codify specific best practices for DevSecOps and require that they be followed, Hunt said in a separate interview.
"One of the problems is that tools aren't being configured and used correctly," he said. "So, first and foremost, we have to agree on what a proper configuration is."
Balancing specificity with flexibility
GitLab customers attending the event said they generally agreed: More specific regulatory requirements would help foster DevSecOps practices -- but only if some flexibility also remained.
"Anything we can do in this space to improve will be great," said Doug Rickert, senior product security manager at Here Technologies, a location services and mapping company based in the Netherlands. "I worry about the balance, though, of having to share all of this information, while also sharing our analysis. For instance, if a specific software library version claims to have a vulnerability, but we've tested and are certain we are not vulnerable, how much pushback will we receive by customers who simply see the library and vulnerable version?"
In highly regulated industries, especially, there is a tendency to take things very literally, said Timothy St. Hilaire, information technology application development manager at BAE Systems Inc. an international defense, security and aerospace company headquartered in Arlington, Va.
"If just the suggestion was given that all developers had to wear blue shirts, blue shirts would be required at all times," St. Hilaire said. "Any prescription would be taken to the extreme. ... The ideal would be multiple examples of acceptable criteria."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.