The 2021 State of Secure Development & ATO in U.S. Government Agencies


 
 

Static Version

Introduction

The US President issued a US Cyber Executive Order in May of 2021 that established new rules for government suppliers to enhance cybersecurity. Recognizing cybersecurity as a “core national security challenge”, it came shortly on the heels of a software-firm hack that involved data compromises across 9 federal agencies and 18K companies. The acceleration of cyber attacks in 2021, against a broader set of industries including governments and public utilities, has led to a need for increased complexity of defense.

The dilemma being confronted by U.S. government agencies is that while they are increasingly under attack, they are also under mounting pressure to modernize their IT systems and consistently deliver better services at lower costs. Government agencies must comply with increasingly stringent cybersecurity requirements to obtain Authority to Operate (ATO). Rapidly developing and deploying secure software in a way that meets ATO requirements, especially within environments where software project volume, complexity, and delivery pace is high and security expertise is in short supply makes attaining ATO or maintaining continuous ATO (cATO) extremely difficult.

This report provides an overview of key findings on a comprehensive study of the topic commissioned by Security Compass. The report quantifies the challenges and opportunities being confronted by US government agencies at the federal, state and local levels. Software development methods, security expertise, developer controls and mitigations, communication approaches, and current approaches to ATO compliant software development are explored.

 

Shifting Security Left

 

Pie chart showing 63% of respondents develop custom software, while 37% do not. Bar chart titled “Priority of ‘Shifting Security Left’ (Introducing Security Early in the SDLC)” shows various priority levels with percentages for overall and agency developing custom software.

 

Overall, over half of respondents (55%) indicate that “shifting left” is either a top priority or one of the top three priorities in the software development process within their organization. This result is even more pronounced among agencies developing their own software, particularly among Federal Agencies.

Improving Software Time to Market

Improving software time to market is a priority for over half of US government agencies.

Bar chart titled “Priority of Speeding Up Time to Market” showing priorities by overall, federal agency, state agency, and local agency. Categories include: Not a priority (Overall 11%, Develop Custom Software 8%), Very low priority (Overall 12%, Develop Custom Software 9%), One of our top 10 priorities (Overall 21%, Develop Custom Software 17%), One of our top 3 priorities (Overall 28%, Develop Custom Software 29%), and Top priority (Overall 27%, Develop Custom Software 38%).

This finding is particularly true for Agencies developing their own software applications.

While a quarter of all Agencies do not measure speed to market, those developing custom software are more likely to and further, Agencies who view speed as their Top Priority certainly do so.

 

This image depicts the different methods of measuring speed to market across three categories: overall, agency develops custom software, and speed is the top priority. It shows that 49% overall, 58% of agencies developing custom software, and 72% of those prioritizing speed use focused metrics or tools. Additionally, 20% overall, 27% of agencies, and 22% of speed prioritizers measure speed indirectly. Lastly, 13% overall, 6% of agencies, and 24% of speed prioritizers do not measure speed to market.

 

Ensuring Secure Coding Best Practices

Bar chart showing various methods to ensure secure coding best practices, such as regular internal training, automated security testing, and secure code review, across federal, state, and local agencies.

 

Donut chart showing the methods used for delivering securing coding requirements. Spreadsheet is used by 47%, email by 46%, and other unspecified methods by 7%.

Training and automated security testing are the two most common means to ensure secure coding best practices. Many still hold to manual security testing as well. The delivery of securing coding requirements remain primarily an even mix of spreadsheets and emails.

Keeping Up With Security Standards

Almost 9 out of 10 (87%) of respondents agree or strongly agree that their teams are doing a good job keeping up with compliance standards. The challenge is the length of time it takes individuals to stay on top of changing compliance requirements. This lengthy time further translates into lengthy processes defining security for both new and existing projects.

Satisfaction with compliance standards across federal, state, and local agencies is shown, ranging from “Not At All Satisfied” to “Extremely Satisfied.” Time spent annually researching and maintaining understanding of standards/regulatory knowledge is also displayed, with categories ranging from “Less than 1 day” to “14 days or more.”

Bar chart showing the length of time to define security for new projects versus existing projects. For new projects: less than 1 day (11%), 1 to 6 days (43%), 7 to 13 days (23%), and 14 days or more (24%). For existing projects: less than 1 day (12%), 1 to 6 days (44%), 7 to 13 days (24%), and 14 days or more (20%).

Implemented Controls

Worryingly, once controls have been implemented, almost a third (30%) do not know how implementation of these controls are tracked. Most use excel for tracking inherited security. Not surprisingly then, the majority believe that tracking inherited security compliance from vendor/infrastructure solutions would help increase the speed of their software development lifecycle.

Bar chart showing methods for tracking implemented controls with 62% manually using spreadsheets, 7% using a toolset, and 30% not sure.

Tracking Inherited Security bar chart shows the percentage of methods used for tracking inherited security. The breakdown is as follows: 39% use Excel/document tracking, 27% use an internal toolset, 14% have no current tracking solution, 11% use a GRC tool, 4% use eMass, 3% specify other methods, and 2% use Xacta.

Bar chart illustrating how tracking inherited security impacts the speed of the SDLC, with categories from not at all faster to a great deal faster.

Authority to Operate (ATO)

Overall, only a third of Federal Agencies are using Continuous Authority to Operate (ATO). A major challenge many US government agencies face is the time to achieve ATO, with over a quarter of respondents indicating that it takes them four months or more to do this, a figure even higher within Federal agencies. A quarter of respondents are dissatisfied or only partially satisfied with their ATO process. 

The image contains three charts illustrating different aspects of achieving Authority to Operate (ATO). The first chart shows the current approach to achieving ATO, with 39% using a standard ATO process, 28% using a fast track ATO, and 33% using continuous ATO. The second chart indicates the time required to achieve authority to operate, with 30% taking 1 month or less, 42% taking 2 to 3 months, and 28% taking 4 or more months. The third chart displays satisfaction levels with the time to achieve ATO, ranging from strongly disagree to strongly agree.

Challenges and Developments

Budget constraints are the most frequently cited impediment Agencies at all levels of government are facing in implementing DevSecOps. Advancements in cloud technology are having a major impact on DevSecOps, although at the Federal level, Secure Software Supply Chain and SBOM are ranked even higher.

Bar chart depicting the challenges of implementing DevSecOps, highlighting budget constraints (57%), managing legal, regulatory & compliance controls (35%), inadequate skill sets (34%), challenges with ATO process/speed (31%), lack of organizational agility (31%), and securing DevSecOps infrastructure & pipeline (27%). The adjacent bar chart shows the top-ranked developments impacting DevSecOps, with cloud advancements leading at 30%, followed by secure software supply chain and SBOM (25%), infrastructure consolidation (22%), ATO reciprocity (17%), and containerization advancements (8%).

Conclusion

Despite the need to modernize IT systems — to produce and deploy higher quality, lower cost, cyber-secure software — many US government agencies at all levels are struggling. Manual processes supported by spreadsheets and document management systems still prevail in maintaining cybersecure systems. Not only does this result in slow software deployment cycles, but it also too often misses the details that DevOps teams require to understand, implement, and validate that their software meets US Federal cybersecurity standards.

Our research suggests that most are doing as good a job keeping up with compliance standards as could be expected under these circumstances. The challenge is the length of time it takes individuals to stay on top of changing compliance requirements — in particular for new software projects — and as follows, the time to achieve ATO.

US government agency software development teams need help. They need help enabling rapid or continuous ATO attainment at scale that translates complex U.S. federal government regulatory standards and frameworks into actionable tasks. They need to implement at greater scale and track in near real time, and to do so despite the budget challenges they face. To reduce the time required to obtain ATO requires automated approaches, both in requirements generation and with continuous assessment of security and risk controls.