SP 800-218r1, SSDF v1.2

Comments Abstract / Executive Summary:

NIST.SP.800-218r1.ipd.pdf

About Mike Sanderson:

I am an application software developer and since 2013 have worked on iPhone apps, working on projects with high security requirements, including as a vendor for a launch partner for Apple Wallet NFC in 2015, on a secure messaging app in widespread use in high-security settings, handling user health data, and independent security research. I am based in New York City and have delivered multiple presentations to professional development groups since 2016. My comments come from the software development perspective, including extensive experience with API design and use.

See attached Excel file for line-referenced comments.

Executive summary / narrative comment:

The framework is welcome, and puts an important focus on the need for secure software development practices.

These comments are primarily concerned that the premise of the SSDF as a “high-level” (line 169) overview with a focus “on the outcomes of the practices rather than on the tools” ((line 164-165) is likely to be frustrating to working professionals at all levels of software development. No one working in software would not implement these practices if they could wave a magic wand and implement them. The issue is who, why, and how.

Therefore, large portions of this SSDF are, in fact, undergirded by information-gathering, training, and education. Everyone wants to do these things, and can’t until they learn how. While the “references” column is the right direction, in the spot-checks, these single-references tend to point to very specific items in the referenced documents, and create a gap between the SSDF practice and the specific technique.

In short, most of these items are in fact, having a preparatory step: undertake information-gathering using sector-specific resources and platform-specific resources.

While that may be obvious, the tone does not reflect that this is in fact the hard part. Instead, the document seems premised on the idea that individuals who consult it are looking for guidance to be told to do these things, and not who, how and why to do them.

Who, Why, and How.

Who: Some of the practices should be implemented by the operating system, the tool vendor, the open-source project in use, a community group, or the organization. Within an organization, it is obvious to the point of tautology that different individuals should be responsible for roles. References to industry-standard terms like “lead developer”, “junior developer”, “project lead”, “technical lead”, etc., will help organizations. The role of forming requirements would be helpful to link to tasks like P.O 1.1 (about identifying external requirements) and P.O. 4.4 (incorporating into agile workflows.) While many software companies and organizations are organized differently, there are some commonalities that would it would be helpful for this framework to engage with.

Why: In the “Notional Implementation Examples,” there is no information about why an organization would undertake this example. Why characteristics of the organization or task would lead to the decision to implement this example. Many of the examples are quite high. Without the reason why, these examples actually make it harder to think of not-listed examples for other cases.

How: This document does not proclaim how, but no information is given — other than referencing to very specific items — as to how. What is needed is a systematic understanding of on what level the implementation of the practices should be developed. This is especially concerning because many of these practices do not need to be implemented on a per-organization level. Instead, the platform owner, the development toolmakers, or the underlying frameworks should find common solutions. This intermediate level — known as “community profiles” in the NIST Cybersecurity Framework 2.0 — is not what this document is supposed to do, but this document would do much better to acknowledge that this level exists.