Recently the Advanced Technology Academic Research Center (ATARC) released a survey done in partnership with the U.S. Air Force. The survey looked at the most common challenges preventing federal agencies from adopting DevSecOps methodologies.
Here are four challenges identified as holding back federal adoption of DevSecOps...
40 percent of survey respondents are using 10 or more tools, while just 28 percent reported using five or fewer tools in their software development lifecycles. This cacophony of tools results in a complex development process, with teams forced to spend a substantial amount of time on tool management instead of building and delivering the applications critical to their organizations’ success.
Development teams are hampered by more than just a cumbersome process for writing and shipping code. Survey respondents most often selected cultural resistance to change as the top barrier to IT modernization and digital transformation within their organizations.
Development teams in the private sector have increasingly turned to Agile methodologies like Scrum and Kanban to build, test, and deploy software in smaller, more frequent releases. But many of their colleagues in the public sector remain frozen in time. Less than a third of survey respondents reported using an Agile methodology like Scrum and Kanban for software development, with a full quarter continuing to rely on some form of waterfall methodology.
Government entities typically require that applications meet stringent security requirements prior to being granted Authority to Operate (ATO). While there are good reasons for this, the result is further delay in getting applications into the hands of business users and the public. Nearly half of survey respondents reported that it typically takes over four months for their organizations to grant an application ATO.
STS has had great success helping clients overcome the common barriers to DevSecOps adoption. Taking the challenges identified by the survey in order:
In a typical DevSecOps environment, the notion of 'too-many-tools', has become a norm because many of these tools perform similar functions. STS has been able to mitigate this by trying to help agency engineers become a SME on one or two of the tools while having, at least, a basic understanding of other tools. STS also provides training resources such as udemy to learn the tools as needed for agency projects. In addition to these, a collaborative environment has helped overcome this obstacle for STS engineers because team members tend to work together as well as share ideas either on a specific project or across projects.
STS provides DevSecOps coaching to client IT teams to help them utilize tools in the most efficient ways possible. STS also provides templates to automate core security tasks by embedding security controls and processes into the DevSecOps workflow. Security can benefit from automation by incorporating logging and event monitoring, configuration and patch management, user and privilege management, and vulnerability assessment into DevSecOps processes.
In DevOps, change is inevitable. STS has been able to help federal clients integrate change by encouraging clients to allow team members and engineers to work on projects that suit their interests. This greatly facilitates change management because it challenges each engineer to be better and have a different perspective on what they currently know, as well as additional skills they nurture over the course of their careers.
Overcoming a resistance to change also comes down to project management 101. There needs to be a solid communications plan in place with robust internal outreach to secure business unit buy-in regarding the “why” and the “what” of DevSecOps initiatives.
The waterfall approach does not promote a good practice of the Software Development Life Cycle (SDLC). We help federal clients adopt the agile approach because there is quicker delivery of product/system and there is room for changes to a system. A key element is to map software development lifecycle (SDLC) gates to DevSecOps automation so that constant meetings and review boards are not required. This also highlights the quality of work being delivered by the engineer, and there are opportunities to discuss any issues or impediments that an engineer might be facing during the development.
ATOs are driven based on the understanding of what the system is going to look like. For example, if there is not enough detail regarding how the system should look and its architecture, it creates room for delay in the ATO because the team involved in approving this ATO will be skeptical of the design specifications and system functionality. STS has been able to mitigate this for clients by ensuring every documentation regarding the ATO process is detailed and contains architecture that would impose little to no risks to the system. The key is mapping controls to automation.
An important effort in this area is the Open Security Controls Assessment Language (OSCAL) out of NIST. OSCAL is a standardized, data-centric framework that can be applied to an information system for documenting and assessing its security controls. The standardized formats provided by the OSCAL project help to streamline and standardize the processes of documenting, implementing and assessing security controls. The automation enabled by the OSCAL formats will reduce complexity, decrease implementation costs, and enable the simultaneous, continuous assessment of a system's security against multiple sets of requirements.
These survey results demonstrate that government agencies need and want help with DevSecOps adoption. When asked what changes were implemented in their organizations that led to increased speed in code release, fully 57 percent of survey respondents pointed to an automated CI/CD pipeline and 57 percent cited establishing source code management. Other common responses included automated testing (39 percent) and toolchain integration (36 percent). STS has a proven track record of success helping agencies achieve such dramatic efficiencies through DevSecOps adoption.
Simple Technology Solutions (STS) specializes in enterprise cloud and DevSecOps transformation for the government. We are:
Our advanced partnerships include Amazon Web Services, Google Cloud Platform (GCP), Microsoft Azure, and best-in-class open source and enterprise CI/CD tools. We are the only small business with AWS Advance partnership status and AWS Government Competency.
Our expertise includes a deep bench of engineers skilled in Agile, DevSecOps, and CI/CD. We implement enterprise DevSecOps environments and fully automated and integrated CI/CD toolchains. We also provide DevSecOps coaching to ensure your team knows how to utilize these automation tools.
STS is a HUBZone company dedicated to using technology to create jobs in underserved communities. We are passionate believers - and living proof! - that technology can be a socioeconomic onramp for minority groups historically left behind the digital divide. We leverage the STS Apprenticeship Program, the first Apprenticeship Program certified by DC Government, to develop individuals in HUBZone communities with little to no IT skills into cloud engineers.