Skip to Main Content

How Army Software Factory Manages Open-Source Code Security Risks

Securing open-source software is a unique challenge, and the federal government is just starting to develop ways to evaluate and minimize security risks associated with its use.

7m read
Written by:
How Army Software Factory Manages Open-Source Code Security Risks
Photo Credit: Luke Allen / DVIDS

Army Software Factory is focused on teaching soldiers proper software security practices as the organization and others across the Defense Department ecosystem increasingly rely on open-source code, which can be a significant cybersecurity risk, as demonstrated by recent high-profile cyber incidents such as Log4j, which Army Software Factory mitigated within 24 hours of discovery.

According to the 2022 Synopsys Open Source Security and Risk Analysis report, 97% of analyzed codebases contain open source code. Sen. Gary Peters (D-Mich.) and Sen. Rob Portman (R-Ohio) introduced the Securing Open Source Software Act last year, which would direct CISA on how to minimize risk in systems that rely on open source code.

The legislation gives CISA a year to publish an open-source code risk framework and directs the agency to support supply chain security efforts.

“We used to have a battle about, you know, open source versus proprietary code, and, of course, it’s no longer a battle; they’ve both become synonymous,” Allan Friedman, CISA senior advisor and strategist, said during a recent CSIS Government Policies for Open Source Software panel. “And open source is a critical part of the organization, of the ecosystem that we have today… But, of course, we’ve started to pay attention to something that is not a new issue, which is, hey, is the stuff we are using actually secure? And even defining that is tricky.”

As DOD implements its software modernization strategy, which calls for a “department-wide software factory ecosystem,” Army Software Factory frequently discusses the importance of understanding secure code with its cohorts.

“As we are training these soldiers to read and write code and understand it, we are also baking in how to do it securely… Because you can write a piece of code that is not necessarily secure and that might not matter, but when you’re designing systems that our warfighters are going to be using, it’s so important that we teach why code security is important,” Angel Phaneuf, Army Software Factory CISO told GovCIO Media & Research last year.

Army Futures Command founded Army Software Factory in 2021 to teach soldiers to write code and fill in software gaps they might encounter in theater.

Prior to the organization’s conception, the idea of soldiers spending their spare time learning technical proficiency and building applications was hard to imagine for senior leaders. But soldiers were able to demonstrate they did not need to rely on outside organizations to build software for them.

Since its founding in 2021, Army Software Factory has built around 15 different applications and garnered nearly 30,000 users.

“It’s definitely something that is shifting and changing, the way that the Department of Defense thinks about software, as well as it’s certainly enriching the lives of soldiers, both those who are receiving the products that we build, as well as the soldiers that are coming here to the software factory to write code for their fellow soldiers,” Captain Sidney Hall, Army Futures Command software engineer, told GovCIO Media & Research in an interview this week.

Hall was a member of the first cohort of soldiers when the factory launched in January 2021. Within six months, they got applications into production in minimal viable form, solving problems soldiers were facing on the ground. From there, the factory iterated and pushed code and features out in a matter of days, sometimes hours.

“We’ve sped up our processes from years .. that are old, waterfall-like processes, and then using more agile-like processes in this organization. We are able to get code into production in the matter of months and then update and push a new feature pretty much in a matter of days,” Hall said.

Soldiers across the force can nominate an Army problem in need of a software resolution, such as a technical problem or an enterprise issue. If an idea shows promise, a team is sent to the site to ensure developers understand the issue, and then developers get to work.

One of the examples of an application developed at the factory is the PMCS app used to help soldiers maintain their vehicles. Previously, the entire process was conducted on paper. “You lose a piece of paper, all the maintenance records are lost,” Hall said. Now, soldiers are able to access the application off of their phones to conduct vehicle maintenance.

The way the factory vets their software is the soldiers poke around to see if there is an existing solution to the problem they are trying to resolve, look further into where the software was made, when was the last time it was contributed to, and if it is being actively updated. They then move it to the platform security team with their own processes. The entire process takes about two weeks to assess whether the soldiers have access to and are able to incorporate a specific tool.

“There are some inherent risks using open-source software. There is the idea that, okay, you can see the source code, though, does it make it more vulnerable? But also, there’s more eyes on the code, so there is possibly more contributions to make the code less vulnerable… The process of scanning and ensuring that there are little to no vulnerabilities in the code is of the utmost priority,” Hall said.

There have been numerous incidents associated with the use of open-source software within government, the most recent one revolving around Pushwoosh, a company claiming to be based in Maryland, California, and Washington, D.C., but actually headquartered in Novosibirsk, Russia, according to Reuters. The Army removed the app containing Pushwoosh code last year, citing security concerns.

“DDS still plans to use open-source software. We presume that the reason the Pushwoosh incident was found was because it was open source — it was there to discover. The quicker we know about a problem, the faster we can fix it. If Pushwoosh had been closed-source, how much longer would it have taken to discover the problem?” Nicole Thomson at DDS told GovCIO Media & Research. “[Open source software community] is a cultural tenet of DDS. We open source many of our products, and our employees also contribute to open source projects.”

Hall says one of the techniques they use at Army Software Factory to mitigate risks associated with open source software is to ensure it is not pulled directly from the internet. They take a snapshot of a piece of software, scan it, and store it in an Artifactory to ensure they have a clean build for app teams to be able to use it. Automation scans code and pushes it into production. Lastly, the factory’s security team always looks out for new CVs. If a new version of CV is released, teams are responsible for updating and patching that software.

“We’ve got some success stories where we’ve had teams go and patch a major vulnerability … as fast as 8 minutes. On average, 24 hours is the rate at which we’ll patch software,” Hall said.

Top cybersecurity priorities at Army Software Factory in 2023 include developing a software bill of materials (SBOM), responding quickly to breaches and software vulnerabilities, and improving how quickly soldiers identify an alternate version or an entirely different piece of software to replace it. Another area of focus will be implementing the Pentagon’s five-year zero trust strategy.

“Having kind of like an Artifactory or some tool that stores our clean unsecure builds or software that we use here, so we know where all of our dependencies are coming from,” Hall said. “We can manage those, update them as we need to, get rid of them if we identify they’ve gone stale.”

Related Content
Woman typing at computer

Stay in the know

Subscribe now to receive our curated newsletters

Subscribe