DevSecOps is such a new and evolving practice that it is helpful to hear from someone who can articulate, “Yes. DevSecOps works in theory and in practice.” In this Innovator edition, Ken D’Auria, Director of Engineering at The Hartford, describes a four-part DevSecOps evolution that may sound familiar to others building secure applications.
D’Auria’s long technology career has spanned the Petroleum Exploration, Insurance and Financial Services industries. He’s participated in the evolution and revolution of software development, including gaining an appreciation of the impact of technical debt when he led a two year effort to address Y2K. To paraphrase the words of philosophers and statesmen, “those who don’t learn from the past are doomed to repeat it.”
He has been with The Hartford since 2008, currently focusing on a DevOps Delivery Framework and DevSecOps integration strategy. With his background and depth of experience, D’Auria has unique visibility into how a working theory can become standard practice.
Generation One: Speed
D’Auria’s introduction to DevOps began a decade ago.
“Our mission was to remove noise from the developers and let them develop. The biggest noise they faced were the team-specific build processes. Every time a developer moved to another project or team, they had to learn a new method. Often developers used their own processes. Instead of collaborating, we were building the Tower of Babel.”
"For example, we did not have a standard source code repository,” D'Auria explained. “We created a homegrown build capability, automating it with scripts. We were putting our executables out on shares. That was first generation and what we considered our pre-DevOps era. We were just trying to provide some speed and standardization to the developers.”
Generation Two: Standardization
Eventually, the team built what D’Auria called a “centrally managed set of pipelines.”
“Generation Two, we standardized on Subversion as a source code repository and purchased a product from UrbanCode called AnthillPro. We used AnthillPro to build our ‘heavy duty’ pipelines that extended beyond Java.”
“It gave us some great capabilities because now we were standardizing on our source code with Subversion. We started adding bells and whistles to encourage our teams to move from their comfort zone to a centrally managed process. We began really focusing on quality, using PMD (Programming Mistake Detector) for source code analysis, and trying to do some rudimentary code quality checking. We also integrated one of our earlier vulnerability tools into the flow and automated deployments.”
Generation Three: Agility & Quality
At this point, open source application usage was growing and developers wanted to use tools they were familiar with and would allow them to grow professionally. The Hartford expanded its digital transformation with formal DevOps and Agile programs. It was clear a transition was emerging.
“Our third generation began with a major platform transformation. We transitioned from an end-to-end solution to a best of breed approach, introducing the likes of Microsoft's GitHub, Sonatype's Nexus Platform, SonarQube, CloudBees' Jenkins, and IBM's UDeploy. We implemented the new framework to provide substantial shift left capabilities, quality assessment processes, and a real focus on ensuring our open source library consumption was safe.”
“The shift-left capabilities greatly reduced rework because now the developer could see the implications of their decisions while working in the IDE. When we didn't have this type of tooling, the developers would go out and pick an open source component they thought would work, and put it into the QA environment. Near the end of the development pipeline, someone would review the results of an application scan and say, ‘Hey, you can't use that!’ The developer would come back to the project manager, and they would agree, ‘We have to go into production next week. We need an exception.’”
Safe open source library consumption became even more important with highly publicized breaches hitting the news, and states beginning to institute regulations to ensure customer privacy and safety. “As a 200 year old company that prides itself on the well-being of our customers, we added automated governance of open source libraries in our applications, as regulations were requiring us to certify safety and security of our applications.”
“We now had the tools and the structure in place to implement automated vulnerability gating, which not only satisfied the audit concerns, but more importantly, protected our customers.”
D’Auria explained that not all was perfect, however. “Unfortunately, our speed to deliver capability, based on our highly centralized and controlled second generation approach, quickly made us realize a need for Rev 3.5. Our small team was challenged with helping our customers transition to the new platforms while continuing to add new features.”
They rearchitected the pipeline approach to manage multiple, technology-specific pipelines that shared reusable components. Then they implemented a pipeline "inner source" model, which allowed the development community to innovate and contribute. This increased the velocity of new features being built into the pipeline, while also energizing and engaging the entire development community.
Generation Four: Practice Becomes the Future
Today, D’Auria and The Hartford are using these practices to continue to innovate and develop future-leaning strategies.
“We are now revisiting the concepts and learnings of our application focused DevOps framework, which is an end-to-end process. It starts with the requirements and the work items, all the way through implementation, post-implementation, incident management, and continuously improving through the feedback loop. With that experience, we are evolving a complete DevSecOps strategy. This strategy encompasses all aspects of an application, not just the application code, but also the infrastructure and content - basically, everything that could impact the users experience and security.” He went on to explain The Hartford’s goal is to have a cloud-enabled, stable and secure, agile environment.
“We’re implementing a formal Open Source Program Office. Our goal is to embrace open source. We aren't only focused on the consumption side of the community, but becoming an active contributing member of the community.”
“Our key objectives are to provide secure and stable products for our customers. That can only be achieved with the proper tooling and processes. And most importantly with an engaged and innovative workforce.”
Ken D’Auria is not only an advocate for DevSecOps, he is providing the vision and leadership the community needs in order to surface patterns and practices that anyone in the industry can use. By sharing his real-world experience, Ken is a true DevSecOps champion and Nexus Innovator.
