The current regulatory framework for software security is a rare moment where the public sector is actually ahead of the private sector.
Paul Davis
Software security remains top of mind for security managers looking to strengthen their cybersecurity defenses. After log4j, more emphasis was placed on providing as secure software as possible with numerous federal regulations and guidelines.
The software regulatory landscape has evolved significantly since the Biden administration’s executive order to improve the nation’s security posture, EO14028. Since the 2021 announcement, a number of government mandates have followed, such as National Institute of Standards and Technology Special Publication 800-218, which provides a secure framework for software development to limit the number of vulnerabilities published in software. In addition, guidance such as Office of Management and Budget Memo 22-18 and Memo 23-26 set guidelines for the security and integrity of third-party software in federal information technology systems. Most recently, the Open Source Software Protection Act of 2023 defines the Cybersecurity and Infrastructure Security Agency’s responsibilities for mitigating the risks associated with open source software. Additional plans from CISA will also continue to be published and will certainly adapt to future standards.
Complying with this amount of federal guidelines can be a daunting task for any security professional, and the list of regulations just keeps growing. Adhering to current guidelines and staying ahead of the deluge of compliance regulations that will surely follow will require the proactivity to act now. While unnecessary compliance may be considered a competitive advantage today, it may be a necessity tomorrow.
Even if you’re not selling to the government – act like you are
The current regulatory framework for software security is a rare moment where the public sector is actually ahead of the private sector in terms of the measures we should take in the software supply chain. As regulations continue to pile up, private sector organizations risk falling even further behind if they don’t take immediate action.
To stay ahead of the curve, organizations should work to comply with federal guidelines, regardless of whether they are a government agency or a supplier. While no one is sure what will happen in the future, ensuring compliance with federal guidelines will ensure teams can continue their operations without having to adapt to the new standards.
This competitive advantage will be crucial and is something that security leaders should consider as the new industry standard to strive for.
How does it look in practice?
There are several tactics DevSecOps teams should employ to ensure their software is as secure and compliant as possible. Some of the most pressing include:
- Define security requirements for software development: Developers must work to the same set of security standards for the entire organization from the start — in this case, government standards. Although not all use cases require the strictest level of security, starting with the strictest security requirements is certainly a best practice.
- Define and use criteria for software security checks: It’s imperative to understand where common vulnerabilities and exposures (CVEs) may be present in your software, but also to set criteria for what constitutes a low-, medium-, or high-risk vulnerability for your organization or use case. While CVE may be considered “high” in certain contexts, if your organization or agency does not meet those contexts, or the chances of meeting those contexts are low, then this does not necessarily stop software deployment.
- Protect all forms of code from unauthorized access and tampering: Whether it’s binaries, open source code, or artifacts, all code must be securely verified before being deployed into your software and stored in a secure environment so that threat actors cannot gain access to other parts of your organization.
- Identify and validate vulnerabilities on an ongoing basis: While a vulnerability may not be present early in the software development lifecycle, or a discovered vulnerability may have been of low risk in certain contexts, this is not true forever. Dependencies change and software evolves, which means that vulnerabilities must be routinely monitored and identified with the appropriate context to ensure complete security.
Regulatory compliance is a complex task that any organization must achieve, especially as new industry standards continue to be introduced. Therefore, it is important to have a comprehensive approach to software security that includes appropriate checks and balances at every stage of development to ensure that all rules are met.
Paul Davis is the Field Chief Information Security Officer for JFrog.
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.