When the Public Sector wins, we all win. Rooting for the security of Public Sector software is something that comes naturally to Veracode. Federal agencies are tackling an incredibly difficult job, and the road to success is meaningful to us all – regardless of our sector or industry. The push for software security came strongly via specific requirements in the Executive Order on Improving the Nation’s Cybersecurity in 2021. Here’s a look at how Public Sector software security is doing two years later.
A Brief Background on the Executive Order on Cybersecurity
We believe the release of the Executive Order (EO) on Cybersecurity in May of 2021 is a long time coming (watch our co-founder explain why). What really stands out to us about this EO is how action-oriented it is. The EO gets specific about types of security controls government agencies must adhere to, and it also includes what to look for in software vendors selling to government agencies.
A key element of the EO is the Zero Trust security strategy, a security model that allows organizations to restrict access controls to networks, applications, and environments. And the EO emphasizes the integrity of the pipeline: organizations must show real evidence that the software development lifecycle (SDLC) itself is secure and that no bad actors can get in the pipeline.
In 2022, Veracode achieved FedRAMP authorization specifically to aid Public Sector agencies in the difficult task of securing modern software. With our comprehensive software security platform, we help agencies comply with the EO by implementing Zero Trust principles across the entire SDLC. Now let’s dig into how effectively secure software development practices are working to reduce risk.
How Effectively the Public Sector is Reducing the Probability of Introducing Flaws
In the State of Software Security 2023, one focus is on what actions can be taken to reduce the probability of introducing flaws. The figure below is of Factors Influencing the Probability of Flaw Introduction with data from our recently released State of Software Security in the Public Sector report.
Before we begin to dissect this data, please note that the baseline chance a flaw is introduced in any given month is 27%, and the factors in the above figure influence that baseline probability.
First, we see that the Public Sector development teams leveraging scanning via API (as opposed to API Scanning) reduce the chance of flaw introduction per month by 3.1 points (from 27% to 23.9%). Teams that integrate scanning via API likely have more automation and control over the development pipeline.
Another valuable insight from this figure is that the age of an app has a higher than typical benefit for the Public Sector than applications in the general population. This indicates that there is a maintained focus on keeping applications secure over time – not only in the first few years.
How Effectively the Public Sector is Reducing the Amount of Flaws Introduced
Additionally, the State of Software Security 2023 investigated factors that influence the amount of flaws introduced (when they are introduced). In the figure below containing Factors Influencing the Amount of Flaws Introduced, once again we see that both age and initiating scanning via API have profound statistical effects on the reduction of risk.
When looking at this figure, note how significant the difference is between Public Sector Applications and All Applications for both Scanning via API and Age of App. Public Sector teams are seeing nearly double the reduction in the amount of flaws being introduced thanks to these secure software development practices. The other factors track closely to the non-Public Sector metrics.
Recommendations for Continued Software Security Improvement
We can glean from this investigation a few key actions that we recommend agencies and enterprises alike take. Let’s start by looking at one of the big factors visible above: initiating scans via API. Programs that keep control over the CI/CD pipeline and leverage automation eliminate ad hoc changes that have not been vetted through the processes. This could be processes like code review, application security testing, change management, and many other steps. Allowing developers to commit outside the guardrails of the application delivery guidelines has perils. A goal for the next three years is to increase maturity in this area—increase automation, and the benefits will follow.
For more recommendations and insights into the security of Public Sector software, read the full Public Sector report, Securing the Future: Unveiling the State of Software Security in the Public Sector.