A whole alphabet soup of agencies, offices and councils are springing up in D.C. and beyond. They’re trying to help us with the software supply chain security problem.
It’s all about cybersecurity supply chain risk management, as the Washington wonks now insist on calling it. Beltway chatter is all C-SCRM this, guidance that and policy the other.
Sounds terrifying. In this week’s Secure Software Blogwatch, we remember Ronald Reagan.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Larf action.
CISA and FASC and NIST — oh my!
What’s the craic? Cate Burgan reports — “C-SCRM Weighing on Minds of Feds”:
“Collaboration with the private sector”
A top official at the Cybersecurity and Infrastructure Security Agency (CISA) said that we can expect to see “much more” guidance from agency cyber gurus in the coming months on Cybersecurity Supply Chain Risk Management (C-SCRM). … Michael Duffy, associate director of the Cybersecurity Division at CISA … explained that his agency has a duty to provide help to organizations by passing along real, sustainable, and effective guidance for good cyber hygiene.
[He] added that one of the most powerful tools the government has is to streamline the flow of information when one agency encounters cyber risks. … He also emphasized that collaboration with the private sector is critical. And not only has the Federal government been abundantly clear that it’s reliant on industry, but also how industry can lend a helping hand when it comes to C-SCRM.
Foreshadowing much? Summer Myatt drops the other shoe — “How CISA Is Tackling Supply Chain Issues & Rising Cyber Threats”:
The government contracting ecosystem has seen major supply chain disruptions over the past few years—unfortunately, recent market conditions, geopolitical developments and increasing cyber threats have only exacerbated these issues. In response … CISA has established a new supply chain risk management office dedicated to help public and private sector partners implement new policies designed to mitigate supply chain woes.
Former General Services Administration official Shon Lyublanovits is leading the new office focused on cyber supply chain risk management, or C-SCRM, and she’s now working on shaping her strategy in the role. “We’ve got to get to a point where we move out of this idea of just thinking broadly about C-SCRM and really figuring out what chunks I want to start to tackle first, creating that roadmap so that we can actually move this forward,” Lyublanovits said.
Meanwhile, CISA Director Jen Easterly … recently met with Rep. Mark Green, R-Tenn, chairman of the House Committee on Homeland Security, to discuss how the committee aims to counter cyber threats. [Rep. Green] urged the importance of establishing CISA “as an information enabler rather than as a regulatory agency.”
Are you ready for some delicious acronym soup? Justin Doubleday doubles down — “CISA establishes new office to ‘operationalize’ supply chain security”:
“Supply chain security conversations”
Agencies have jump-started efforts to develop their own C-SCRM programs, while new laws and executive orders continue to pile on additional requirements and considerations for managing risks in the technologies the government purchases. While some agencies like NASA have long been leaders in managing supply chain risks, Lyublanovits said others are still struggling with the basics.
In 2018, Congress [established] the Federal Acquisition Security Council [FASC] to develop governmentwide policies and criteria for security IT supply chains. The council has designated CISA as its “information sharing agency,” said Sean Peters, [FASC] deputy program manager.
NIST has since published new cyber supply chain guidance to help organizations manage potential risks in IT products like malicious functionality, counterfeit components or other vulnerabilities. … FASC helped contribute to that guidance.
Officials pointed to the need to understand industry’s perspective on supply chain challenges. … Jon Boyens, deputy chief of the computer security division at NIST, said companies are participating more in supply chain security conversations than they were a decade ago: “I actually think we’re kind of in the midst of relationship changes between acquirers and suppliers.”
A big part of the problem is pulling from repos such as GitHub and PyPI. captain veg waxes maximalist:
Don't use them, folks, unless you're prepared to audit the code yourself. … It illustrates the stupidity of making your enterprise reliant on … projects which pull in … third-party code that you haven't yourself validated.
But also beware of the toolchain. Matt Rose would smell as sweet — “red flag for security teams on software supply chain risk”:
“Risks can be lurking in the tools”
The process to follow when encountering a security incident is similar to the one followed by firefighters. The first thing to do is put out the fire. … Next on a firefighter's agenda is determining the cause of the fire [but] these investigations can get complicated. People think these events are as simple as A causes B, but in reality, there can be a host of interconnected events.
Organizations have to not only be concerned about malware being injected into a compiled object or deliverable, but also of the tooling used to build them. A typical software supply chain starts with the … IDE producing code that goes into the software repositories, which are used during Continuous Integration and distributed through Continuous Delivery to the cloud or a data center.
Software supply chain risk isn't just about the code or the compiled artifact, it's [also] the technologies, the tooling, that actually creates the artifact itself. … Supply chain … risks can be lurking in the tools that make up the process itself. If all the testing is done on the artifact — whether it's software composition analysis, static application security testing, penetration testing or whatever — something will be missed unless the core competencies, like IDE and CI/CD, are examined.
Sounds like a great plan. Now go get management buy-in. b0llchit sounds slightly sarcastic:
But, but, that would require expertise and well-designed environments. Not just playing the infinite import game and having the not-my-problem attitude. Who will pay for all that extra work, knowledge and hours?
Which could prove a challenge, according to S. Raschid Muller:
The lack of cybersecurity awareness addresses critical gaps in the managerial decision-making of supply chain officers at the executive level who do not address technology integration and have not adopted cybersecurity as a threat to supply chains. The skills gap exists because 2.4 million jobs need to be filled by 2028.
[There are] critical gaps in the managerial decision-making of Supply Chain Officers (SCO) at the executive level. Research suggests that C-Suite Level SCOs do not address technology integration and have not adopted cybersecurity as a threat to supply chains.
Meanwhile, Headley_Grange neatly sums up the challenge:
That would involve engineers. You know — people who can understand the use-case, risks, current state-of-the-art, the related security issues, turn them into requirements and then get it … coded, tested, into production and maintained as threats evolve.
Those same engineers could sort out your systems so they're both resilient and less prone to attack. Of course, this would cost a lot more than just downloading stuff off the internet for free.
You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or firstname.lastname@example.org. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.