Our Roundtable Sessions are invite-only events hosted by peers for peers that bring together a select group of senior IT leaders from across industries for topic-driven, intimate dialog on current trends and topics. The group met remotely to discuss why companies are still struggling with DevSecOps, led by the CIO of a construction and real estate development company. This Session was sponsored by Wabbi.
DevSecOps, which stands for development, security, and operations, is a set of principles that allow organizations to make security an inherent part of their software development life cycle. Using DevSecOps, organizations can automate security controls at various stages of app development. This includes training developers regarding security and equipping them with required tools, breaking organizational silos and fostering collaboration between security and development teams, and promoting a culture of security-as-a-shared-responsibility across the organization.
Multiple attendees agreed that the definition of DevSecOps can vary based on where you are in the journey. In the beginning, you may think that investing in tools for static code analysis and vulnerability scanning may suffice. But as your company grows and you notice the rise in supply chain and open-source attacks, you realize that security needs to be baked into all the processes.
DevSecOps is an approach to automate security and make it an intrinsic part of the software development lifecycle. It requires a shift in culture, tooling, mindset, and architecture. A successful DevSecOps implementation requires the entire organization to develop a shared responsibility toward security. An attendee exclaimed that DevSecOps is not a technological problem; it’s usually a people or process problem. Most organizations fail because they spend a lot of time and money on tooling and automation but forget to revamp their processes and culture. Tools can automate the mundane and boost productivity to an extent, but unless your development and security teams are actively collaborating, you won’t be able to achieve DevSecOps.
At the beginning of the discussion, different participants shared where they currently stood in the DevSecOps journey. A technical lead said that they are bringing in new resources and trying to instill an automation and security mindset in their workforce, which will be critical in their journey to implementing DevSecOps. A director of security mentioned that they plan to train their security ops and engineering teams before they embark on their DevSecOps journey. A CTO added that security and DevSecOps are a part of everything they do in their organization. They didn’t have to shift left; they started left. A senior development executive told the audience that they are investing in tools to bridge the communication gap between their InfoSec and development teams. Lastly, a CEO remarked that to achieve DevSecOps, they are trying to create feedback loops between security and engineering teams.
An executive said that they are struggling to prioritize security risks and vulnerabilities. Their toolsets produce a lot of alerts and potential risks, but their engineers are finding it hard to prioritize them. Where should they start? Which of these can be false positives? How do they separate the highest-risk vulnerabilities from the rest? To solve the prioritization problem, engineers need to be trained so that they can analyze data and filter out areas that need their immediate focus. There is also a need to invest in security tools that can help contextualize risk.
A speaker mentioned that their end goal is to establish a delicate balance between security and developer experience. They want their guardrails to enforce security without being overly restrictive. Developers should be taught how to write secure code and should be prevented from installing potentially malicious packages, but their ability to consistently push software to production shouldn’t be hindered. Another executive commented that DevSecOps should allow them to set security checkpoints across all their pipelines without hampering efficiency.
One attendee shared that their end goal is to build repeatable patterns. You do integrations around repeatable patterns, and you build applications around repeatable patterns. The power of repeatability, i.e., build once, use always, can make it easier to incorporate security into applications and build scalable infrastructures.
A contributor used the word “glue” to refer to the importance of integrations in implementing an efficient and rigorous security infrastructure. They said that gluing everything together to implement feedback loops can be the next big value. Virtually everything has a web API now, making it easy for different applications and components to talk to each other and share data. Not only can glue make your system more optimized, but it can also help you contextualize risk by establishing relationships between security issues and business impact.
Third-party collaborations don’t come without security risks. More cyberattacks are stemming from third-party integrations than ever before. So, how do you assess risk before onboarding the third party? And how do you manage their access lifecycle?