# Automating SSDF Controls Requirements on NIST Software Repositories Proposal

Project Title:
Primary Author: Alexander Stein
Primary Author Division: 773
Secondary Author(s): Nikita Wootten
Additional Author(s): -
Submission Type: Seeker
Subject Area: Cybersecurity

## Context of Proposed Research

The ubiquity of software has slowly increased demands for secure software development practices. The velocity of these demands dramatically increased as of late, fueled by high-profile attacks exploiting insecure software development, resulting industry adaption, and commensurate US government policy changes. Executive Order 14028 brought forth new guidelines in secure software development. Now developers, inside and outside government, are beginning the important long-tail of work to apply prior guidance, this new enhanced guidance, and align their current people, processes, and tools with them.

NIST ITL has a significant role in such standards, particularly SP 800-218 [1], the Secure Software Development Framework. We in ITL communicate this expertise outwardly to industry, but it is equally important that we demonstrate within our own internal development teams' practices. Many of those teams release software publicly, not just as a by-product of research, but for external stakeholders to leverage in their own secure software development lifecycles. That long tail of aligning macro-level guidance, whether prior or new, and micro-level practice, is applicable within ITL and equally significant. Even though, software for any given niche has custom requirements and must be adapted to guidance’s best practices, common patterns of reusable process and tools emerge. Even at the organization level, NIST specific requirements (MIDAS and Policy S 1801.03 checklists [2]) have analogues in different federal agency projects sharing similar themes with the SSDF. It is just that the SSDF provides a generalizable framework and finer focus on the details of key practices in secure software development.

Reference compliance patterns with these standards, and readily available tools to measure and document conformance with them, will be highly valuable with ITL, NIST, and the broader industry. They will significantly reduce the legwork for developers to map higher-level standards requirements to implementation details in their project.

## Technical Plan

This exploratory research will use blended user experience (UX) techniques and software prototyping to create reusable compliance patterns and tooling for secure software development. These patterns and methods will easily integrate into NIST developers’ projects and enable them to demonstrably measure how a particular project meets the intersection of NIST’s institutional (MIDAS, Policy S 1801.03 [2]) and the Secure Software Development Framework (SSDF) requirements in SP 800-218.[1] First, the research team will review these intersecting requirements to categorize which requirements are conducive to reusable templates, automated scanning, and automated enforcement. Secondly, UX research will inform software design, addressing the most frequent pain points around security requirements. These inputs will prioritize focus on which subset of the requirements are the focus of the prototype. Additionally, these will also inform developer-friendly approaches to measuring SSDF compliance with preferred developer tooling (used not only by NIST, but also the broader industry) and document the status of the measured requirements in consumable way. Presentable, easily consumable documentation will benefit developers communicating amongst themselves and with briefing relevant stakeholders who must necessarily understand their efforts in the context of a larger information security program. Thirdly, our tools will be prototyped and implemented iteratively with additional from successive UX feedback sessions. Finally, tools will be made available as part of GitHub source code repository templates for new projects, and will also baseline existing source code repositories and keep the integration updated for ongoing use.

Upon completion, due to required adoption of SSDF by federal agencies and observable uptick in voluntary adoption across industry, the software prototype(s) can be made generalizable, and configuration can allow for adoption by different consumers inside ITL, NIST, federal agencies, and industry at large.

## References

[1] NIST SP 800-218: Secure Software Development
Framework (SSDF) Version 1.1 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
[2] NIST S 1801.03 https://inet.nist.gov/system/files/documents/2021/12/29/final-s-1801_03-ver-3.pdf
[3] https://bestpractices.coreinfrastructure.org/en
[4] https://openssf.org/blog/2021/08/11/introducing-the-allstar-github-app/

## Potential Impact

Society takes the stability and resiliency of software for granted. The Secure Software Development Framework (SSDF)[1] and matching industry efforts continue to underline that the best guarantees for stable, resilient software start as early as possible: that is with the developers of the software as they design and implement. The long-term impact of SSDF, both for US government software projects and those throughout industry, is contingent on early adopters leading by example: sharing their lessons learned, and in the best case, sharing techniques and tools to communicate them. The Linux Foundation had proven this in 2016 with Core Infrastructure Initiative (CII) and the Badge App program. In the wake of significant hurdles to open source maintainers of key projects like the OpenSSL cryptography library to easily adopt secure software development practices, the Badge App guides onboarded developers and track their progress.[3] The continuation of similar efforts since August 2021 with the newly formed OpenSSF and the AllStar tool for secure development and supply chain guidance built into GitHub is showing early signs of similar success.[4] We believe that this project can show actionable examples of SSDF practices and tasks, beyond the notional implementation examples in the recent 800-218 publication. It will also provide reusable tools of immediate use to developers, first inside NIST and soon after the industry at large. This project can follow the shining examples of the CII and OpenSSF, and apply it to deservedly popular SSDF guidance so that the path to easily achievable secure software development shines even brighter.

## Budget

Personnel Budget (\$): 50,000 (2 .25 FTEs)
Names(s) of Personnel: Alexander Stein, Nikita Wootten
Travel Budget (💸\$): N/A
Purpose of Travel: N/A
Other costs (\$): \$0.00
Description of Other Costs: N/A