Health Agency CISO Looks to Increase Security in Software Transparency Requirements
![](https://cdn.nextgov.com/media/img/cd/2021/10/14/online_testing_and_assessment_quality_monitoring_vector_id1143672593/860x394.jpg?1634242959)
z_wei/istockphoto
Robert Wood aims to improve security while fostering faster mission execution from a DevSecOps “BatCAVE” at the Centers for Medicare and Medicaid Services.
The Centers for Medicare and Medicaid Services’ plan to implement President Joe Biden’s executive order on software procurement will require more than the bare minimum from contractors.
The executive order will require agencies to obtain a software bill of materials—typically described as an ingredients list of the code libraries that make up a particular application—from vendors. But not all SBOM standards are created equal. Leading standards for their formulation include SWID (Software Identification), SPDX (Software Package Data Exchange), and Cyclone DX, and some only require basic licensing or version information. Proponents say gathering even that superficial information is an important first step while others argue realizing the full security potential of SBOMs would require revealing deeper levels of the software supply chain.
“We are we are starting to lay groundwork for how we ingest Cyclone DX, the more security-oriented SBOM standard, into our data ecosystems so that we can start incorporating it into the asset visibility functions that programs like [the Continuous Diagnostics and Mitigation program] were intended to to drive,” said Robert Wood, chief information security officer at CMS. “We are focused on the Cyclone DX standard, in particular, at CMS.”
Wood spoke during an event Thursday hosted by the Advanced Technology Academic Research Center. He highlighted the SBOM requirement in the executive order in connection with a DevSecOps effort he calls the BatCAVE—a continuous authorization and verification engine. He believes security teams should be more open about their processes to create buy-in and sees the development, security and operations model, where all those functions are happening concurrently, speeding teams’ ability to create tools and services.
“We don't want teams to have to go through, you know, a two-to-four week security impact analysis, another, you know, multi-month [authority to operate] process for changes that they want to make,” Wood said, noting the significant amount of custom application development that occurs at the agency.
He said slow-moving processes like the Federal Risk and Authorization Management Program can end up impeding the agency’s mission. The security-focused SBOM will be part of what he describes as a “declarative state” system that will allow that kind of verification in real time.
“What we're aiming to do is build on the success of CMS' cloud migration cloud adoption strategy and shift towards declarative state,” Wood said. “It's about moving more state into the codebase, and when it's in the codebase, we can write tests for it ... we can build a release gate for it, all of that stuff that helps us push compliance down into the code base, and if it's in the code base, it can be inferred automatically … that is probably the thing that is like keeping us like really excited, really engaged, really motivated.”
Wood noted resistance to the SBOM requirement from some in industry. But he said the more security-focused SBOM standard is crucial to the larger goal of achieving greater visibility across the federal enterprise.
“There's a lot of pushback that we see from tech vendors around producing SBOMs as part of procurement,” he said.
But, he noted, “The spirit of [CDM] is not just about what assets are running on your environment, but like, what is your environment actually made of at any given point in time, and if we consider, third-party technology, third and fourth-party technologies, SBOMs help create that fingerprint of what that thing is made of.”
RELATED PODCAST
NEXT STORY: The CISO reporting structure is broken