Best practices for tackling software security compliance complexity

Software security remains top of mind for security leaders looking to strengthen cybersecurity defenses. In the wake of log4j, a heightened emphasis has been placed on ensuring software is as secure as possible with a number of 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 its release in 2021, a number of government mandates have followed, such as National Institute for Standards and Technology Special Publication 800-218 which provides the secure software development framework to limit the number of vulnerabilities released in software. Additionally, guidance such as the Office of Management and Budget’s memo 22-18 and memo 23-26 set out to establish guidelines for the safety and integrity of third-party software on federal information technology systems. More recently, the Securing Open-Source Software Act of 2023 defines the responsibilities of the Cybersecurity and Infrastructure Security Agency to mitigate risks associated with open-source software. Additional roadmaps from CISA will continue to roll out as well and will surely lend themselves to future standards.

Complying with this volume of federal guidelines can be a daunting task for any security professional, and the list of regulations is only growing. Adhering to current guidelines and staying ahead of the deluge of compliance regulations sure to follow will require proactivity to act now. While today non-required compliance may be seen as a competitive advantage, tomorrow it may be a necessity. 

Even if you’re not selling to the government – act like you are

The current software security regulatory landscape is a rare moment in which the public sector is actually ahead of the private sector in terms of the measures we should be taking in the software supply chain. As the number of regulations continues to pile up, private sector organizations risk falling even further behind if they don’t act now.

To stay ahead of the curve, organizations should work towards complying with federal guidance, regardless of whether or not they are a government agency or vendor. While no one is certain of what will happen in the future, ensuring compliance with federal guidelines will ensure that teams can continue their operations without having to readjust to new standards.

This competitive advantage will be crucial and is something security leaders should consider a new industry standard to which to aspire.

What does this look like in practice?

There are several tactics that DevSecOps teams should deploy to ensure their software is as secure and compliant as possible. Some of the most pressing include:

• Define security requirements for software development: Developers have to work from the same set of security standards organization-wide from the start — in this case, government standards. While not all use cases require the strictest level of security, starting from 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 set criteria for what constitutes a low, medium or high-risk vulnerability for your organization or use case. While a CVE may be considered “high” in certain contexts, if your organization or agency doesn’t meet those contexts or the chances of it meeting those contexts are low, then it doesn’t necessarily have to stop software from being deployed.
• Protect all forms of code from unauthorized access and tampering: Whether it’s binaries, open-source code or artifacts, all code needs to be securely vetted before being implemented in your software and stored in a secure environment so threat actors cannot gain access to other parts of your organization.
• Identify and confirm vulnerabilities on an ongoing basis: While a vulnerability may not be present at the beginning of the software development lifecycle, or a vulnerability detected may have been low risk in specific contexts, this does not hold true forever. Dependencies change and software evolves, meaning that vulnerabilities must be routinely monitored for and identified with appropriate context to ensure total security.

Regulatory compliance is a complex task for any organization to achieve, particularly as new industry standards continue to be introduced. Thus, it’s important to have a comprehensive approach to software security that includes the appropriate checks and balances at each stage of development to ensure all policies are met.

Paul Davis is 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.