Safety Detective’s Aviva Zacks sat down with Chetan Conikee, CTO of ShiftLeft, and asked him how his company helps other organizations keep their data secure.
Safety Detective: How did you get into cybersecurity and what do you love about it?
Chetan Conikee: I started in cybersecurity more than 20 years ago, and over the course of my career have gained experience in authoring and architecting mission-critical software, including building web-scale distributed infrastructure, personalization algorithms, complex event processing, fraud detection, and prevention in investment/retail banking domains.
I’ve been lucky enough to be a part of early founding teams at a number of incredible startups that have gone on to be acquired by established organizations, and this process is what has made me truly passionate about the cybersecurity industry. Cybersecurity is one of the most dynamic industries. Security is a concern for almost every organization today, regardless of vertical, so there is constant room for evolution and growth. New technologies are being introduced, attack vectors are evolving, and hackers are more intelligent than ever. I love building solutions and helping organizations solve one of their most challenging problems: “How do I protect my organization?”
SD: Why do organizations need to learn about DevSecOps?
CC: More organizations are adopting DevOps for the benefits of agility and velocity, but with these benefits also come unintended security consequences.
First, organizations are building their DevOps pipelines to be as fast as possible, which means the amount of time allotted for security is automatically reduced. This is because security has traditionally been a slow, manual process, so as organizations release software and applications with increased velocity, security is more disconnected from this process than ever. When you consider that organizations release software and applications on a weekly or daily basis—and that code is becoming more complex thanks to the increased reliance on third-party dependencies and open source libraries—it’s impossible for security to keep up.
Second, many organizations are taking a siloed approach to DevOps and security. Engineering and DevOps managers are doing one thing around static code analysis and vulnerability programs, while CISOs and threat analysts are doing another in building threat modeling and aggregating incidents via security information and event management (SIEM). While all of these departments are working individually to ensure breaches don’t occur, the siloed approach makes it easier for attackers to exploit weak points. Further, as more computer systems are built on SaaS models, the quality of the software is of the utmost importance. By embracing DevSecOps, organizations can more effectively find security flaws (either in production or deployment) and better harden software against attacks.
SD: How can organizations best implement DevSecOps into their strategy?
CC: When most organizations consider how to implement DevSecOps, many default to automation because it has the potential to make DevOps fast, predictable, and reliable. While automation is a critical factor to DevSecOps’ success, embracing automation for automation’s sake is not going to be what drives success. For example, automating a security scan that’s generating inaccurate results is no better than the same manual, slower scan as it was before. Even if the process runs itself, security is not being improved and DevOps teams will choose to ignore results because they’re unreliable. The point of inserting automated security in the development cycle is to confidently alert and escalate issues, ultimately getting the right vulnerability information to the right developers at the right time.
This is what enables developers to efficiently reduce mean-time-to-remediation. It is the core of “shifting security left”—when you insert security as close to the beginning of the development process as possible—and should be the goal of any DevSecOps strategy.
SD: What tools can developers use to integrate and automate security from the beginning without impeding on velocity?
CC: Being able to automate application security, while still being fast and accurate, is vital to organizations’ success. It is critical to implement tools that have the ability to identify and mitigate vulnerabilities at the same pace in which new applications are created. It is also crucial to have unprecedented scanning speeds, to ensure development teams can insert security without slowing down their CI/CD pipeline.
With that in mind, there are only a few solutions on the market that fit these requirements and combat the traditional issues of static application security testing (SAST), web application firewalls (WAF) and runtime application self-protection (RASP). ShiftLeft’s suite of products, including Inspect, Protect and Ocular, dramatically reduce scan time speeds, false positives, and automatically create policies for every version of every release to reduce WAF/RASP inaccuracies.
By adopting tools that understand how software and applications are vulnerable in development, as well as how applications are actually being used in production, developers can get a much fuller picture and automating security will become much more productive.
SD: What are some of the key challenges DevOps teams face today when it comes to integrating security into the development process, and how does DevSecOps help address these?
CC: Often, a website breached via a vulnerability serves as the starting point for other major attacks – including an attacker’s ability to move laterally across the network with insider access, to escalate privileges, and to eventually gain access to more critical resources such as databases, co-located applications and more. In other words, the vulnerabilities introduced into applications and software during development have the potential to lead to complete network takeover, and the siloed approach of DevOps and security isn’t helping to mitigate these risks.
DevSecOps addresses these issues by bringing together different capabilities and tactics to create an interconnected fabric, including:
- When utilizing static and dynamic testing to discover vulnerabilities, it is imperative that an entry-exit point framework has a life beyond a single run cycle. This framework is akin to security-as-code as it is auto-generated by accessing software and defines the shape of evolving application code in terms of its workflow and insecure states. It can be archived, version-controlled and accessed to generate value elements. Using this framework, developers can evaluate it against predefined policies to determine negative or positive drift.
- Creating a red team attack strategy to protect application surfaces. It creates a baseline policy for instrumented Runtime Protected Agent RASP to protect against known and unknown threats. The runtime agent monitors for imminent attack vectors leading to fundamental changes in observed behavior, which in turn feeds back to augment policies.
- Reducing available time for the intruder to breach a system and perform arbitrary harm by implementing software-defined provisioning. This enables rolling upgrades without downtime.
SD: How do you see cybersecurity developing in the next five years?
CC: When it comes to the future of application security, we will continue to see security shifting further left with an increasing number of security and compliance controls getting embedded earlier into the DevOps lifecycle. There will also be more conversations and emphasis around the security of the DevSecOps pipeline in and of itself as an important risk surface. The greatest opportunity I see, however, lies in successful DevSecOps implementations requiring reduced security friction and therefore serving as a catalyst for innovation in existing security tools, enabling them to generate more accurate and relevant insight or actions.
Ultimately, in an attempt to solve these problems, in the next five years, I anticipate that we’ll see more application security suites so that products can more easily work together and share data across all aspects of the software development lifecycle.