 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Security tends to be a checklist for developers — one more thing to tick off on a long list of tasks to check off while creating an application. Time and time again, security pros have said security needs to start with developers. But developers haven’t always felt the same way. That’s changing, said Josh Lemos, who became GitLab’s new chief information security officer in June.
“Security is becoming more of a domain, similar to performance and observability, where developers have some portion of security as a functional responsibility within their role, whether that means using some kind of paved road, or whether that means that they have to know what a good security design pattern is to implement that in their codebase,” Lemos told The New Stack. “And for me, that’s encouraging, because for a very long time, it wasn’t that way.”
But what really needs to change is that security needs to be baked into development tools, he said. In his previous roles with companies such as ServiceNow, Square and Cylance, the goal was to design good security patterns into the developer tools so that developers can manage security as part of their normal workflow, he said.
“What we did was we build systems that would have Infrastructure as Code components ready to deploy in a modular fashion, we abstracted away the complexity of authentication and authorization interfaces for APIs, and developers could just adopt the design pattern that was there in place and not have to write their own and reimplement it,” he said, adding that it’s a boring solution but it created consistency and drove better security outcomes.
If a developer didn’t use that security design pattern, his team would investigate to find out why not.
“It allowed our security team to then focus effort on creating an alternative design pattern, if that was necessary,” he said.
That’s why he came to GitLab, he said. He realized there are thousands of companies that don’t have the resources to engineer their own security patterns.
“If I could express that same value for 1,000s of companies and millions of developers, that could be a lot more powerful in terms of a contribution to the broader infosec landscape,” he said. “We’re running millions of the world’s build pipelines as well. So it’s not just the source code repository aside, but also the building and deploying that software.”
GitLab is focused on opportunities to improve automation and velocity, two themes that he said keep coming up with developers.
“We’re going to have to build our own security tools that automate at the same velocity, and that are able to evaluate security issues at the scale of software development, at the speed of software development, rather than having security as a gatekeeping function, which has been on the way out for the last 10 years,” he said.
Gitlab is looking at both traditional methods as well as machine learning to examine developer concepts such as code coverage and integration tests. Machine learning can provide visibility into security vulnerabilities and fixes for them. For instance, it can help with vulnerability and reachability issues, such as: is this code ever called when there’s a security vulnerability that comes with it, and whether it’s fixable.
“That allows us to prioritize our vulnerability patching efforts or remediation efforts based on empirical data that we know to be true about the accessibility of those vulnerable code functions,” he said.
He also sees meaningful use cases with generative AI that can accelerate GitLab’s security program. For instance, a purpose-built chatbot trained on open source code could allow developers to ask questions as they code, like is it safe to use this package, or provide a secure design pattern for a function for this version, and get an answer.
“Those are very powerful potential use cases for self-service in the developer workflow, without leaving their development environment to find those answers, without having to track down an application security engineer, without having someone necessarily review their code at human scale,” he said. “Security is going to have to keep pace with automation and software velocity, and it’s going to happen at a programmatic scale, not a human scale.
