State of Software Security: Insight Into Government Sector Application Security And Guidance For Policy Makers

In 2015, the United States Office of Personnel Management (OPM) announced that it had been the target of two massive data breaches. These breaches are thought to be a result of gaining valid user credentials to the systems they were hacking through social engineering, as well as through a malware package which installed itself within OPM’s network and established a backdoor. Attackers then escalated security privileges to gain access to a number of OPM systems. The first attack resulted in the theft of approximately 21.5 million records of people who had undergone background checks – though they may not have been current or former government employees. In the second breach, the personnel data of 4.2 million people had been stolen. Think: full name, birth date, home address and Social Security Number.

While there are no silver bullets for solving today’s cybersecurity problems, its clear government organizations have a long history of vulnerabilities and breaches. In fact, government organizations continue to underperform those in other industry sectors when it comes to the security of its software, according to our State of Software Security 2015 report. We continue to see the same trend year-over-year with only slight improvements. In the State of Software Security 2017 report, applications developed by government agencies remain the least secure of all industry groupings, measured by pass rate against OWASP Top 10 policy. Further, applications also had the highest flaw prevalence of any industry group for cross-site scripting (49 percent), SQL injection (32 percent), and cryptographic issues (48.3 percent). To dive deeper into the findings, please download the State of Software Security 2017: Government Sector infosheet.

There are several reasons that government software continues to be insecure, including the fact that it is still developing applications with older programming languages known to produce more vulnerabilities, and they’re not always fixing the flaws that they find. It’s also likely that the relative inability to be agile and to try new things, as a result of strict acquisition regulatory practices, prevents government engineers from implementing a DevSecOps approach to development. Certainly, the need to align with compliance requirements may not always reflect modern best practices, and may prevent procurement personnel from utilizing feedback loops and nimble, iterative processes.

Through our conversations, we understand that the government sector is trying to improve its processes and learn from the private sector. The Modernizing Government Technology Act, which was signed into law last year, has made a point of prioritizing both security and agile management practices as government looks to refresh its IT infrastructure. We also appreciate that there are many layers to the changes that need to be made, ranging from creating a culture of security to helping those in procurement to have access to the technical expertise when selecting vendors. If you work in the government sector and you’re not sure where to start with appsec, our Policy Maker’s Guide to Application Security can help get you up to speed on the basics, and provides guidance for policy makers interested in securing the world’s software.