To build DevSecOps, you need both modern tools and cultural changes
The last few years have seen enterprises building security into their software development lifecycles, but similar efforts in the public sector face a number of unique challenges related to both tooling and culture. Invicti partnered with Checkmarx and the Advanced Technology Academic Research Center (ATARC) to organize a webinar discussing the requirements for building DevSecOps in government agencies.
Your Information will be kept private.
Your Information will be kept private.
The ATARC webinar and panel discussion
Organized under the title “Shifting Security Left with DevSecOps,” the joint webinar brought together industry and government experts to talk about the everyday realities of application security efforts in government agencies and the latest tools available to support them. The panel included:
- Edmond Kuqo, DevSecOps Lead, U.S. Navy
- Ian Anderson, Lead DevSecOps Engineer, Naval Surface Warfare Center (NSWC)
- David Sperbeck, GDIT, DevSecOps Architect, U.S. Census Bureau
- Ted Rutsch, Federal Account Executive, Invicti Security
- Rusty Sides, Public Sector Technical Sales Director, Checkmarx
Watch the full webinar recording below and read on for a summary of the discussion:
The undisputed benefits of early security testing
Participants were in agreement that incorporating security testing and remediation from the earliest possible phases of development is beneficial not only for application security but also for keeping the software development process running smoothly. Vulnerabilities that are found early on are far easier and cheaper to fix than issues identified in later phases. As organizations increasingly embrace more agile development methodologies, shifting security left is also becoming a necessity to prevent costly release delays caused by late-stage security testing and remediation. Modern security testing tools can work at multiple stages of the development and testing pipeline to make this a technical reality – but tools are only one side of the story.
Cultural resistance in multi-generational teams
Building security into development is as much about culture as it is about tools and technologies. All panelists working within the federal government made it clear that resistance to change and cultural issues are major challenges on the road to shifting security left in the software development lifecycle (SDLC). Apart from the inertia of decades of more traditional waterfall development, these barriers are also compounded by the generally slower pace of change enforced by compliance requirements.
A unique aspect of application development in government agencies is that teams will often combine experienced professionals who have been developing government software for decades with fresh talent coming straight out of college. These groups will differ widely in skill sets, experience, and the ability (and willingness) to embrace unfamiliar tools and workflows. Younger developers entering the workforce may be frustrated by long-established processes and systems, while existing developers may be uncomfortable with technological shifts and the introduction of more agile approaches.
The skills and generational gaps hitting hard
Developer education is a crucial part of any application security effort so that developers know what is expected, how to do it, and what tools and processes to use. While application security testing is by no means new, in the past it would have been primarily a manual process. Experienced developers know how to write secure code and work with security testers to remediate security defects, so it often falls on them to pass these skills on to their younger colleagues. Modern security testing tools can now shoulder some of that burden, freeing senior developers to focus on their main job of developing applications.
As more and more senior developers in government organizations approach retirement, this skills gap will only become more severe. Having the right tools and educational resources is crucial to ensure that the new generation of developers will have the same ability to identify and mitigate vulnerabilities while also moving to more agile methodologies.
Modern tools ease the transition to DevSecOps
Beyond alleviating some of these cultural and training challenges, advanced security testing tools are a fundamental requirement for building highly automated development pipelines that embed security testing and remediation into the development process itself. Solutions are now available both for static (SAST) and dynamic application security testing (DAST) that integrate directly into the developers’ issue trackers so that security defects are reported and fixed like any other bug. This is in stark contrast to more pedestrian security testing processes where external testers would simply present developers with a PDF listing all the defects that need to be fixed, starting an arduous cycle of verification, isolation, remediation, retesting, and finally deployment.
As Ted Rutsch explained, Invicti is especially well-positioned to help with this in web application security testing, offering DAST solutions such as Invicti that provide accurate automatic confirmation for many vulnerabilities to greatly reduce the workload for security teams and developers alike. By delivering detailed, actionable vulnerability reports directly to the developers complete with technical information and remediation guidance, government organizations can make security testing an efficient part of their automated SDLC at each stage of their journey towards DevSecOps.
For more information about building DAST into your web application development pipeline, read the Invicti white paper: Why you need DAST in your SDLC