DevSecOps: 4 Steps for Mitigating the Next Cyber Attack in Your Federal IT Environment


Across the U.S. government, Federal CISOs and CIOs are working to address potential vulnerabilities on the new “front lines” of defense: cybersecurity and the software supply chain. The SolarWinds and Colonial Pipeline cyberattacks raised more widespread visibility and understanding of the impact of these threats, and in the months that have followed, a cadre of new mandates, draft legislation, and operational directives are taking aim at solving existing vulnerabilities and preventing new ones.

In recent news, the Cybersecurity and Infrastructure Security Agency (CISA) issued a new binding operational directive that gives Federal civilian agencies a six-month clock to remediate known vulnerabilities in software and hardware used in Federal information systems, including both on premise and cloud-hosted.

In addition, the White House’s cyber Executive Order (EO) issued earlier this year specifically highlights current issues with software supply chain security and lays out stringent requirements for improvement, stating, “The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended. The security and integrity of ‘critical software’ — software that performs functions critical to trust… Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.”

President Biden has asked the National Institute of Standards and Technology (NIST) to work with industry organizations and vendors to create a new framework for improving software supply chain security.

Software developers are truly on the front lines, and while more and more Federal agencies are embracing the DevOps principles of “release often and quickly,” the ability to also release securely is essential. Software updates in some application environments can take months or even years to deliver – which is problematic if the update is addressing a vulnerability or an urgent mission requirement.

So what steps can Federal agencies and their mission partners take to secure the full development lifecycle and software supply chain – including development, updates/patching, and at the same time enable rapid software delivery? Here are a few recommendations you might consider:

Step 1: Unite Security Teams with DevOps Teams

While developers recognize that security is important, oftentimes it’s not their top priority. More typically, DevOps teams prioritize delivering new capabilities and features to the business and customers, often as part of larger digital transformation initiatives. And developers often view security as something that will slow down deployments.

When developing software, it’s important for security teams and DevOps teams to work closely to “shift left” and effectively bake security into every stage of the development process.

The security team should communicate new, needed features and security guidelines to the DevOps team. In turn, the DevOps team must have some security knowledge, should get in the process of “thinking like a hacker,” and provide a realistic deployment plan for updates to ensure they are secure.

Step 2: Write Once, Use Many

Under the Department of Defense’ (DoD) Platform One initiative, developers working within command operations can access a central repository of secure, tested and validated software components that have been hardened to the DoD’s specifications. The program – known as Iron Bank – empowers developers to deliver custom mission applications rapidly and securely. It also gives vendors, including JFrog, Continuous Authority to Operate (C-ATO) with government defense organizations.

Step 3: Implement a Multi-Pronged Testing Approach

Following initial development, or prior to significant updates, all software must go through rigorous multi-pronged security testing. The tests should be performed by the third-party developer, and, ideally, also by an external security auditor. The external audit should include manual research, automated static analysis, and automated dynamic testing.

Another key testing process is red teaming, where a team of specialists mount a false attack on an agency’s systems. It is a valuable tool that agencies should use more often and can be implemented during the design process as well as the qualification cycle.

Red teaming has traditionally been used to test critical software. But, today, the risks are greater – driven by the risks associated with software supply chain attacks and by the tremendous proliferation of connected devices. Projections estimate there will be 24 billion IoT devices in use worldwide by 2026. According to Gartner, spending on the worldwide government IoT market is expected to jump 22 percent in the next year. This means millions more entry points for threats.

With an exponential rise in the number of supply chain attacks over the last year, now every system is critical and can provide a point of entry for malicious code. For example, the Army might not test software for a payroll system as rigorously as software for a weapons system. The payroll system, however, could be the entry point to attack the entire network. Red teaming identifies weaknesses and vulnerabilities in systems that can be mitigated prior to an attack, protecting the entire network.

Step 4: Implement Vulnerability Disclosure; Leverage the CVE Program

Establishing a vulnerability disclosure program (VDP) for your own organization is essential. This process involves two steps – sharing and receiving information. Organizations can tap into existing VDPs for an added layer of protection – specifically to deal with unforeseen situations that might include unusual or creative attack vectors. A VDP creates a system for organizations and researchers to easily communicate, identify vulnerabilities before they can be exploited, protect essential data from being accessed, and stay a step ahead of cybercriminals. As a best practice, use the knowledge base in VulnDB, and contribute newly discovered vulnerabilities to help make the cyberworld a better, safer place.

Another valuable resource is the CVE program. Their mission is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. There is one CVE Record for each vulnerability in the catalog. Partners made up of public and private sector tech organizations (including JFrog, Red Hat, Google, and Microsoft) publish CVE Records to communicate consistent descriptions of vulnerabilities. Cybersecurity and IT professionals worldwide use CVE records to coordinate their efforts for addressing critical software vulnerabilities.

Taken together, these measures will provide Federal agencies and military organizations with the best opportunity to innovate and deliver rapid custom applications and updates, securely.

About Asaf Karas
Asaf Karas is the chief technology officer of security for Jfrog.