In late August, the Advanced Technology Academic Research Center (ATARC) sponsored a Webinar in conjunction with Checkmarx and Invicti entitled, “Shifting Security Left with DevSecOps.” This virtual panel discussion featured prominent application development leaders and experts from both the government and private sector coming together to discuss how the adoption of DevSecOps can help accelerate the software development lifecycle (SDLC) while improving application security.
And that’s something that the participants in this virtual panel discussion were uniquely qualified to discuss. Many of the speakers were responsible for leading application and software development teams within organizations that rely heavily on the capabilities delivered through software for mission success, and that prioritize security and mission assurance. Each were either working to shift security left in their application development processes – or providing the tools needed to do so.
The participants included:
- Edmond Kuqo, DevSecOps Lead, U.S. Navy
- Ian Anderson, Lead DevSecOps Engineer, Naval Surface Warfare Center (NSWC)
- David Sperbeck, GDIT, DevSecOps Architect, United States Census Bureau
- Rusty Sides, Public Sector Technical Sales Director, Checkmarx
- Ted Rutsch, Federal Account Executive, Invicti Security
All the participants agreed that working security into the development process –shifting security left instead of waiting until after the development process to test applications for vulnerabilities – was an effective way to accelerate application development and eliminate vulnerabilities earlier in the development process.
And when it comes to identifying those vulnerabilities, earlier is better. As Rusty Sides explained, “The earlier you find the vulnerability, the less expensive it is to remediate that vulnerability, and the lower the chance that it makes it into deployment.”
However, the process of shifting security left and embracing a DevSecOps approach to application development within an organization is neither cut and dry, nor simple. Each of the panelists that worked within the federal government made it clear that shifting security left in the SDLC is a change or evolution within their organization that requires embracing the correct tools, and navigating through turbulent cultural changes.
Cultural clashes in a multigenerational developer workforce
While the benefits of shifting security left within the SDLC are undeniable and inarguable, large barriers exist within the federal government that make the transition something that’s easier said than done. And one of the largest barriers involves the cultures at play within federal agencies.
The application development teams within government agencies – as described by the panelists – are multi-generational teams that blend young, right-out-of-college developers with experienced professionals that have been coding for the government across multiple decades. These disparate groups bring different skills to the table, have varying degrees and amounts of experience, and all want to work and learn differently.
“You have people coming in directly from college, then you have developers that have been working there for 40 years,” Ian Anderson described. “How do you get them to develop the same? How do you train them?”
Edmond Kuqo also has experienced frustration within his development teams as the Navy transitioned from a traditional, waterfall approach to application development to a DevSecOps approach. Kuqo noted that younger developers entering the workforce may find established processes and systems frustrating, while existing developers may be uncomfortable with change and the introduction of new systems.
In fact, for many of those experienced developers, Kuqo explained that the process could require them, “…to forget what they’ve learned over the last 20 years and learn the new platforms.”
“The earlier you find the vulnerability, the less expensive it is to remediate that vulnerability, and the lower the chance that it makes it into deployment.” – Rusty Sides
Also universal among panelists was the need for training to get developers on the same page, and comfortable with new processes and systems. This sentiment was echoed by Rusty Sides, who explained that “embracing a secure culture requires AppSec training.”
However, training younger developers to develop securely can be a challenge, in that it often falls to more experienced developers and takes them away from the task of developing applications. This was a challenge shared by Ian Anderson, who asked, “As you have junior developers coming into the organization, how can you train them up without having a senior developer spending a lot of time working with them?”
Thankfully, another critical component of shifting left – advanced tools and applications – cannot only assist in baking security into application development but can also help alleviate some of these cultural and training challenges within organizations.
Shifting left with static analysis and code bashing
While changing culture – and training development teams and managers – plays an enormous role in shifting security left in the SDLC, the transition to DevSecOps can also be helped enormously by embracing advanced tools and applications designed to automate security processes that have traditionally been done manually.
One of the tools that assists with this is Static Application Security Testing (SAST) – which scans code as it’s written for known vulnerabilities and alerts developers to their presence. Incremental scanning gives developers the ability to quickly remediate and verify any vulnerabilities discovered in their application’s source code before it gets to the security team for review. This can drastically accelerate the SDLC and reduce the cost and time needed to remediate vulnerabilities. As Ted Rutsch explained, these tools can help to, “…automate the process of validating vulnerabilities [and] significantly cut down the AppSec team’s review time.”
Multiple panelists expressed how today’s advanced static analysis and interactive code scanning tools can play a large role in improving application security. According to Ian Anderson, “Static analysis tools [can] allow developers to…see the problems and vulnerabilities before they deploy applications.”
“You have people coming in directly from college, then you have developers that have been working there for 40 years. How do you get them to develop the same? How do you train them?” – Ian Anderson
As we discussed previously, training newer developers to code securely has often fallen on the shoulders of the organization’s more experienced developers. These tools can alleviate the need for that time-intensive training process by identifying and alerting developers to the vulnerabilities both in the code they write, and in the open source code they utilize in the development process.
“There is a legacy workforce out there that carries a lot of knowledge of mitigating vulnerabilities. As they retire, we need to pass that knowledge on,” explained Ted Rutsch. “But we can also put tools in place that can give [younger developers] the same ability to identify and mitigate vulnerabilities.”
If that’s not enough, there are also advanced developer training tools entering the marketplace that integrate into the development process and utilize gamification to train developers to write more secure code. Tools such as these could play a large role in training all members of a multi-generational development team to develop more secure code.
As government organizations and agencies have embraced digital transformation initiatives, their reliance on applications has increased. This has resulted in agencies demanding more from their development teams and demanding that the application development process accelerate. Shifting security left and embracing DevSecOps can ensure that development teams can expedite the SDLC without sacrificing security. But to do so, they’re going to need to change their culture, and embrace next-generation tools that can automate processes and make the transition easier.