Integrating security into the development process [Q&A]

Historically, security has been treated as something as an afterthought in the IT industry. In more recent years though there has been pressure to introduce 'security by design' to ensure that products are developed with best practices in mind.

We spoke to David Melamed CTO of Jit to find out about integrating security and how security tools can be used by developers not just security professionals.

BN: How did you get involved in the development security space?

DM: As a software engineer (going way back), I understood that security is a critical piece to delivering high quality software. Over the years, I invested more time and effort to study the domain, and had the specific opportunity to get hands-on in cloud security at CloudLock (later acquired by Cisco). In the CTO office I performed deep research on real-world cloud security threats, and was even one of the researchers who contributed to the Top 10 Serverless Security Threats (before Serverless took off as it has now). Today, at Jit, I have brought that domain expertise from many years as a hands-on developer, architect and security researcher to cover the entire scope of end-to-end security through an open and accessible framework to all.

BN: What are the main challenges with implementing security tools?

DM: In a nutshell -- there are a lot.

The sheer diversity and amount of security tools make this a really difficult landscape to navigate. Not only are there different categories from detection to prevention, code scanning, runtime vulnerability detection, but they can also come in many forms too, from executables and scripts, to API-based tools, SaaS, and open source packages. The biggest and most commonly noted challenge though, is that each of these tools is a world of domain expertise unto itself, and comes with its own 'language', method of implementation, interface and output. All of this together creates a steep learning curve to achieving end-to-end security coverage for the many layers of today's cloud native stacks -- as well as a lengthy 'time to full security coverage'.

Though the most critical piece of security in such a landscape is having a predefined plan, essentially a north star for your product security. This is because even if you do integrate all of the right tooling, but your security goal is not well-defined, you will never know if you are correctly managing your security posture and whether there are any significant gaps in your product security.

BN: How should teams integrate security into the development process?

DM: Embedding security into development should start as early as the first line of code, and as a practice and culture, even before that in the design and threat modeling phases. There are so many layers our products are composed of today -- from the code, to the integrations and third-parties (often called the supply chain), infrastructure -- with a diversity of runtimes, and much more. All this together has created many entry points for would-be attackers, and none of these can be overlooked.

That said, we do believe that teams can start small and iterate with a minimum viable security approach -- similar to an MVP, you don't need to build a fortress from day one, just a baseline plan that will provide you with the minimum set of controls to cover the major exploits across all of these categories. There are plenty of really great open source tools to get you started, we have a pretty good roundup on our blog of the Top 5 Open Source Security Tools all devs should know about (and a great talk!)

BN: Can you explain the role of open-source projects in the cybersecurity space?

DM: Open source security has evolved incredibly over the years, and today there are a substantial amount of pretty awesome open source security tools -- that have been a game changer for the industry. From OWASP ZAP (the most widely adopted web application scanner -- maintained by our own distinguished engineer, Simon Bennetts), to Gitleaks that Jit has chosen to support and sponsor, among many others from KICS, to Prowler, Semgrep and more.

These projects have lowered the barrier to entry for security, where to date much of the security landscape has been closed and premium suites of software that aren’t always accessible to smaller and growing companies. Many OSS security tools are best of breed today and provide very good coverage for common needs, and have served to provide much-needed innovation, as well as understanding what security experience (similar to developer or user experience) should look like to truly enable widespread adoption.

BN: What is your opinion on the future of security for companies with fast-paced development teams?

DM: Companies that won't know how to embed security into native developer workflows in high-velocity engineering organizations will be left behind. There's no time for friction or learning curves, security tools need to be optimized for developers. They need to provide clear output, and not just be informational, with a focus on being actionable with built-in remediation. We believe the security tools that will be game changers are those that come with a fix-first mindset not just be issue-driven (developers are sick of long lists of vulnerabilities with know understanding how to fix them).

What's more, the other half of it, is that eventually with the growing and constantly evolving threat landscape, we'll see that the security (dev) tools that get this right, will eventually be the enabler (yes you heard correctly -- the enabler) of high-velocity engineering with safety. The stakes are too high today, and companies are one pull request and breach away from major disaster. Engineering organizations that will be able to deliver fast, while maintaining continuous security will be the ones who take the lead.

Image credit: mikkolem/depositphotos.com