Cybersecurity regulations are becoming increasingly stringent on both sides of the Atlantic. In the United States, the Biden administration has issued Executive Order 14028, while the European Union is rolling out its own set of rules, the Digital Operational Resilience Act (DORA). As these regulations take effect, organizations must adapt to meet the new requirements and ensure the security of their software supply chains.
We spoke to Eric Fourrier, CEO and co-founder of GitGuardian, a code security company, about the new security regulatory landscape and how to meet the requirements.
Hi Eric, to set the stage, could you explain what Executive Order 14028 is?
In 2020, SolarWinds fell victim to a cyberattack where hackers compromised its build systems and injected malware into official updates for its Orion network monitoring software. As a result, the malicious code was distributed to tens of thousands of systems, including those belonging to the Departments of Homeland Security, State, Commerce, and the Treasury. This incident served as a wake-up call for both the industry and the government, highlighting the critical importance of addressing threats to the software supply chain.
In response to this breach and other hacks targeting the federal government, the Biden administration issued an Executive Order outlining measures to enhance cybersecurity. The order places a strong emphasis on software supply chain security, recognizing its critical role in protecting both government and private sector systems. It mandates the development of new standards, tools, and best practices to enhance software security, including the use of automated tools to maintain trusted source code supply chains.
How would you define “software supply chain security”?
In modern software development, developers rely on a variety of third-party packages, libraries, and frameworks, collectively known as “dependencies.” These components form the “supply chain” of the software, much like parts sourced from third parties in manufacturing. These dependencies can introduce vulnerabilities into the software that uses them, whether due to innocent mistakes or malicious intent.
A prime example is the Log4J component, widely used in the Java ecosystem for logging. When a vulnerability was discovered in Log4J, many companies were unaware that their purchased Java-based software even included it. If the software vendor was no longer in business, there was no way to obtain updated versions with a fixed Log4J component or a version without Log4J altogether. Even a year after being identified as a critical threat, Log4J remained a significant risk, largely because many companies either didn’t know they were vulnerable or faced a daunting task in replacing the affected software.
Understanding the components in the supply chain of the software you use is essential for responding effectively when a related vulnerability is discovered. As a software developer, you need visibility into your supply chain security, and your customers are realizing they need it, too.
How does software composition analysis help me meet 14028’s requirements?
Software composition analysis (SCA) helps verify and prove your supply chain’s safety based on current knowledge. It enables quick responses to new vulnerabilities as they emerge. Executive Order 14028, Section 4, mandates:
- Regular automated vulnerability checks and remediation
- Maintaining accurate, current data on software components and provenance
- Recurring audits and control enforcement
- Providing purchasers with a Software Bill of Materials (SBOM)
SCA automates vulnerability checks, generates reports to maintain required data, and facilitates audits. It is also a prerequisite step for creating SBOMs.
While primarily applicable to federal agencies and their software providers, similar requirements are being adopted in the private sector. In late 2023, the US SEC will require publicly traded companies to report on cybersecurity risk management. SCA on internal software and obtaining vendor SBOMs help demonstrate compliance with best practices.
There’s been a lot of buzz recently about the SEC’s “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure” rule. Can you give us a quick rundown?
Yes, it was all over the news in November 2023 when a ransomware gang tried to punish a victim for not paying by reporting the victim’s lack of disclosure to the SEC. The main concern that rocked the industry was the requirement for hacked companies to report any breach that “constituted a material impact” within just four days of making that determination, which is an incredibly tight timeline. But here’s the kicker: the rule comes with no official definition of what constitutes a “material” impact. So if a company takes months to investigate and determine it was materially impacted, the 4-day reporting window would only start after that lengthy investigation.
The rule’s second part requires companies to regularly disclose (in annual reports) their specific actions to “assess, identify, and manage material cybersecurity risks.” By mandating consistent, timely, and predictable reporting of risk management strategies, the SEC aims to stir the industry in the right direction. Yet it remains to be seen if this will significantly impact overall cybersecurity practices, as it will likely mean additional work for legal and investor relations departments to get the ball rolling.
The European Union is not lagging behind either: can you give us a quick overview of the EU’s Digital Operational Resilience Act (DORA)?
You are right, the EU is also gearing up towards hardened cyber resilience through laws like DORA. As a cybersecurity company based in the EU that helps customers with application security and risk management, we’ve been closely monitoring the development of this act.
DORA aims to improve the European Union’s financial systems’ resilience to digital risks by establishing standards in various areas. The first drafts, published in January 2024, will go through the EU’s legislative process before taking effect.
The rules focus on 1/ incident reporting by setting thresholds and standards for categorizing and measuring severity; 2/ Defining standards for risk management tools, methods, processes, and policies, which may require auditing current security measures and providing periodic updates; and 3/ security testing, including the full gamut of test from source code reviews, vulnerability assessments, open source analyses, network security assessments, to physical security reviews, questionnaires, scenario-based tests, and penetration testing.
GitGuardian offers solutions that can help address the risk management, incident management, testing, and reporting requirements mandated by these upcoming regulations.
What advice do you have for getting prepared to comply with these new regulations?
My advice would be to think strategically about what programs can be started now to be fully prepared for more questions and/or audits from regulators in the coming years. These laws are just the beginning, trying to enforce some essential practices that represent a basic level of security hygiene. Great improvements can already be made on these basics.
A typical example is secrets – the programmatic credentials that allow software systems to communicate with each other securely. Implementing measures to detect and remediate hardcoded secrets across the entire software supply chain is essential, yet many organizations don’t know how secrets are managed across their whole operation or how mature they are regarding leak detection and remediation (you can get a rough idea in 5 minutes with this questionnaire). Continuously scanning code repositories, both public and private, as well as other development tools like chat messages, project management tickets, and documentation, is a good example of baseline hygiene organizations can start implementing today.
Taking care of the vulnerability scanning, focusing on high-impact vulnerabilities, will go a long way to show diligence in improving to regulators in case of an incident or increased scrutiny. Frameworks such as SLSA for supply chain trust or Secrets management maturity model can give you a sense of your current situation and where to go from there.
Related Categories