Methodologies, Toolchains, and Security, Oh My! Insights from the 2021 ATARC Federal DevSecOps Survey (Part 2)
The Advanced Technology Academic Research Center (ATARC), in partnership with the U.S. Air Force, conducted a large scale survey on the current status, challenges, successes, and vision for the future in the Federal DevSecOps landscape. In this series of blog posts we’ll be reviewing the results from the 2021 ATARC Federal DevSecOps Survey and highlighting key takeaways from the responses of the nearly 300 technical professionals in the public sector that participated.
By: Traci Robinson-Williams, Technology Business Strategist | Digital & Cultural Transformation Evangelist, GitLab
Our last post focused on the importance of maintaining a continuous integration/continuous delivery (CI/CD) pipeline and the challenges inherent in source code management (SCM). In today’s post we’ll be homing in on the critical nature of instituting modern planning tools and methodologies, the benefits of toolchain integration, and explaining how to “shift security left.”
Failure to Plan is Planning to Fail
Fully 43% of survey respondents attributed their ability to increase the speed of their release cycles to putting the proper planning tools and methodologies in place. This makes intrinsic sense. Successful product teams need to be able to capture, discuss, prioritize, and define new requirements and use cases in an iterative fashion. Agile methodologies have become popular in large part because they enable business and technical stakeholders to clearly visualize the progress of development teams and prioritize new features according to their importance.
Unfortunately, only a minority of survey respondents reported using an Agile methodology like Scrum and Kanban for software development, with a quarter continuing to rely on some form of waterfall methodology. This represents a missed opportunity. Development teams in the public sector can improve both the speed and quality of their releases by implementing technology that, at a minimum, delivers a visual board to show their flow of work, a task list for each work item, and health statuses for each item that clearly demonstrate which items are on track, need attention, or are at risk of missing deadlines. Doing so gives stakeholders the insight they need to detect problems before they become critical and shift priorities to accommodate changing mission priorities.
Too Much of a Good Thing
When development teams adopt new tools they do so for good reason—typically because a tool automates a routine task that would otherwise eat up valuable development time. The risk is that in their desire to automate, development teams actually add complexity, increasing what is called the toolchain “tax”— the overhead of maintaining multiple standalone tools. This in effect recreates the problem these tools were meant to solve, simply substituting toolchain management for other rote tasks.
Exponential toolchain growth can be seen clearly in the public sector, with just 28% of survey respondents reporting using five or fewer tools in their software development lifecycles. Indeed, a substantial minority of 21% reported using an eye-popping 12 or more tools! Many teams are beginning to recalibrate as a result, with 36% of rapid software delivery gurus exhorting teams to “reduce your number of tools and simplify your toolchain.” In practical terms, development teams are better off relying on a unified DevOps platform that manages the entire toolchain with the visibility provided by a single application. Such an application delivers numerous benefits, including reducing costs thanks to less administrative overhead, reducing risk with a single set of permissions, and increasing the pace of issue resolution by keeping all stakeholders on the same page.
Moving Security Left
In the understandable rush to release code faster, many important facets can be forgotten, including security. Yet security concerns have a bad habit of making their presence known, with many development teams seeing their applications put on hold, or even scrapped altogether, because they’re deemed vulnerable. As a result, many teams have adopted a strategy of “shifting security left”—bringing security checks earlier into the development process—as part of a wider move to a DevSecOps methodology that treats security teams as equal stakeholders throughout the software development lifecycle.
This can have real results. 29% of survey respondents credited early security vulnerability feedback and remediation with saving critical time in the development process. However, moving to a DevSecOps methodology requires both operational changes [e.g. including cybersecurity stakeholders in the planning process and technological changes or giving developers access to static application security testing (SAST) and dynamic application security testing (DAST) reports]. Both changes can be augmented with a solution like GitLab, which compares vulnerabilities between source and target branches during merge requests and delivers SAST and DAST reports for the purposes of both remediation and to help developers build secure coding practices.
Look forward to the final edition of this series as we tackle the challenge of achieving authority to operate (ATO) in federal agencies. In the meantime, if you’re a developer working at a federal agency, we’d love to hear from you! Please let us know how you’ve improved your planning process, simplified your toolchain, or moved to a DevSecOps methodology.