IT visionary Marc Andreessen once quipped that “software is eating the world.” A decade or so later, application-layer security concerns are eating at software developers, especially in the public sector.
Much of the angst stems from open-source software, which benefits developers by allowing them to streamline management of common features and tasks – and focus more development time on critical features or business logic that are unique to the software they are building.
Yet despite these advantages, its popularity makes open-source software a target for cybercriminals. It can frequently contain undiscovered security vulnerabilities that could threaten an app, a website, or an entire network. In the absence of rigorous security checks, developing software using open-source components can be a gateway to future security vulnerabilities. That’s because open-source components can introduce security vulnerabilities – just as first-party code can.
In government, the challenge is acute. Compared to other sectors, applications used by government agencies have the highest rate of known security flaws, according to the recently released State of Software Security (SOSS) annual report. Analyzing data from 20 million scans and half a million applications, researchers found security flaws in 82 percent of public sector applications.
The government’s record of remediating known security flaws in software doesn’t compare favorably with other sectors. Across sectors, about 30 percent of vulnerable libraries remain unresolved after two years. For the public sector, that statistic almost doubles to more than 55 percent and lags the cross-industry average by over 15 months. And a meager overall fix rate of 22 percent puts the public sector at heightened risk of successful cyberattacks against critical government applications. (The fix rate of other sectors is similarly poor.) At a time when the administration has signaled its commitment to improving the customer experience of citizens who access digital government services, software security flaws are ticking time bombs.
Improve open-source security
Open-source software is ubiquitous and it’s not going away – for good reason. Flexible and cost-effective, open-source software is the foundation of most applications across all industries.
Yet the challenge of security vulnerabilities in the public sector is hard to ignore. Who hasn’t received “free credit monitoring” as compensation for a security breach that compromised personal information? Last year, a software vulnerability discovered in Apache’s Log4j, a popular open-source library and logging utility, created a way for hackers to take control of devices on the internet.
Often, there is little correlation between the popularity of open-source software and resources available to their developers for security. Those projects often have little to no funding, making security a challenge for maintainers. The issue has begun to draw the attention of public officials who have identified the link between software security and public trust as an area of concern. In January, the Biden administration met with major IT companies to discuss improving security of open-source projects, including prevention of security defects, finding them when they occur, and accelerating the repair of faulty code.
Build security into apps from the start
There is a solution. Agencies and their IT partners must take a “shift left” approach to security—moving it to the beginning of the software development lifecycle (SDLC) instead of placing it at the end—and continue to vigilantly monitor for security vulnerabilities throughout the entire lifetime of the software.
The prerequisites of a robust software security program require application developers in the public sector to continually monitor applications throughout the SDLC, efficiently identify security flaws, and quickly remediate identified vulnerabilities.
Typically, developers of open-source software are quick to issue patches for newly discovered vulnerabilities. The risk to organizations escalates when patching is delayed. Open-source software that’s not adequately maintained doesn’t age like wine; it ages like milk.
New vulnerabilities requiring remediation are being discovered all the time, yet public sector agencies, as noted, are notoriously slow to patch known security flaws. Exacerbating the problem at many agencies is the large volume of patching that’s required–a massive buildup of technical debt–and insufficient resources for fixing them.
Gain visibility with automated analysis
What’s needed is an automated solution that alerts users when to act. Software composition analysis (SCA) tools analyze applications’ open-source elements, including the flagging of open-source code that’s out-of-date or in need of patching. Gaining visibility is a big step in the direction of software security because you can’t fix what you can’t see.
Without a software composition analysis tool, an agency could spend months determining which of its applications contains a newly discovered vulnerability.
Second, agencies must have the capability to perform gap analysis and to determine which products are most out of date and vulnerable – and which vulnerabilities are most likely to impede agencies’ missions.
It’s important to prioritize remediation because agencies don’t have the capacity to easily wipe out accumulated technical debt – much the same way that you wouldn’t expect somebody who had racked up $100,000 in credit card debt to sort it out in the first month.
Practice Rigorous Security
To efficiently remediate vulnerabilities, developers must practice rigorous security hygiene as codified in the maxim “fix early, fix often.” And it’s never too early. Developers taking more aggressive action in the form of a hard shift left are acknowledging the symbiotic relationship between security and development teams – a departure from the outmoded practice of bolting security onto software after it has been developed.
Shifting left will prevent organizations from accumulating more security debt. Over time, security debt will decline.
Ideally, a software security solution will behave as a comprehensive, unified platform, rather than a mix of disparate tools. The platform must be capable of performing multiple testing types at various stages of the SDLC, with the goal of ensuring compliance to policy and reducing the time needed to identify and remediate flaws – from years to days, or even hours.
Compared to proprietary applications that are coded from the ground up, the process of developing applications built with open-source software is faster, more flexible, and less costly. None of those benefits matter, however, if a hacker can exploit an undetected vulnerability in embedded open-source code. With the security tools that are available today, there’s no reason for that to happen. Hewing to rigorous security protocols – from the outset of an application build and continuing through deployment – allows developers to benefit from open-source resources without being consumed by security concerns. With the right tools, they can have their code and security too.
Chris Eng is the chief research officer at Veracode, an application security company based in Burlington, Massachusetts.
Have an Opinion?
This article is an Op-Ed and the opinions expressed are those of the author. If you would like to respond, or have an editorial of your own you would like to submit, please email Federal Times Senior Managing Editor Cary O’Reilly.
