The document discusses the Secure Software Development Framework (SSDF) developed by NIST, focusing on practices for mitigating software vulnerabilities during development. It outlines key areas such as preparing the organization, protecting software, producing secure software, and responding to vulnerabilities, while emphasizing the importance of communication and training. Finally, it highlights the need for organizations to adapt their practices to align with the SSDF to build trust and ensure API security.

1. SSDF & API Security Presentation
Prepared by Bill Jones
Softrams - Security Practice

3. AGENDA
• What is SSDF?
• Practices – In a Nutshell
• Why does it matter?
• What can we do?
• API Security Impact?
• Most Importantly

4. What is the
SSDF?
• Secure Software Development
Framework – Recommendations for
Mitigating the Risk of Software
Vulnerabilities. *(In the Development
Environment)
• When we think about API security
often, we think about testing the APIs
with application penetration and other
static/dynamic testing techniques and
much more.
• We need to shift [insert direction] with
our focus and apply practices with
policies using the SSDF.
• Say Hello to the NIST 800-218.

5. How I View Practices?
NIST PROVIDES PRACTICE AREAS AND EXPECTS
ORGANIZATIONS TO USE THEM TO BUILD OUT
POLICY THAT WORKS BEST FOR THE
ORGANIZATION.
PRACTICES ARE BROKEN OUT AS THE MAIN
OVERARCHING CATEGORY FOR WHAT IS
COVERED UNDERNEATH IT, LIKE AN UMBRELLA.
THE DOCUMENTS ARE ORGANIC AND NEED TO
BE UPDATED OVER TIME AS PROCESSES CHANGE
WITHIN THE POLICY AREAS OR FRAMEWORK.

6. Practices – Not API Security Specific
Prepare the Organization (PO): Ensure that the organization’s people, processes, and
technology are prepared to perform secure software development at the organization
level and, in some cases, for individual development groups or projects.
Protect the Software (PS): Protect all components of the software from tampering
and unauthorized access.
Produce Well-Secured Software (PW): Produce well-secured software with minimal
security vulnerabilities in its releases.
Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases
and respond appropriately to address those vulnerabilities and prevent similar
vulnerabilities from occurring in the future.

7. • Practice Data At A Glance
Practices Tasks
Notional Implementation
Examples
Define Security
Requirements for Software
Development (PO. 1)
Identify and document all security
requirements for the organization’s
software development infrastructure
and process, and maintain the
requirements over time.
Educate affected individuals on
impending changes to
requirements. (Ongoing Updates)
Protect All Forms of Code
from Unauthorized Access
and Tampering (PS. 1)
Specify which tools or tool types must
or should be included in each
toolchain to mitigate identified risks,
as well as how the toolchain
components are to be integrated with
each other.
Use version control features of
the repository to track all
changes made to the code with
accountability to the individual
account.
Design Software to Meet
Security Requirements and
Mitigate Security Risks (PW.
1)
Use forms of risk modeling – such as
threat modeling, attack modeling, or
attack surface mapping – to help
assess the security risk for the
software.
Review vulnerability reports and
statistics for previous software
to inform the security risk
assessment.
Identify and Confirm
Vulnerabilities on an
Ongoing Basis (RV. 1)
Gather information from software
acquirers, users, and public sources
on potential vulnerabilities in the
software and third-party components
that the software uses, and
investigate all credible reports.
Use threat intelligence sources to
better understand how
vulnerabilities in general are
being exploited.

8. Why does it matter?
Communication!
Your organization will be able to supply your SSDF implementation to external entities and build
trust, your API may receive more consideration within the industry sector you’re targeting. Most
importantly again, building trust within your software! Secured from the start following policies and
practices to avoid potential data leaks (APIs love to leak data)!
While the SSDF is high-level, your adaptation of the example practices will allow you to define what works best
for your organization. There is no one size fits all! With this freedom to adapt your policies to meet defined
practices, you’ve begun to create more secure APIs (software too).
For APIs you’ll want to focus on modular code that has been hardened and follows defined policies for updating.

9. What can we do?
Communication!
Your organization will be able to supply your SSDF implementation to external entities and build
trust, your API may receive more consideration within the industry sector you’re targeting.
Regarding API security many of the implementation examples will help ensure all areas are
covered to develop secure interfaces from the get-go.
Implement the SSDF and begin training your organization on the importance of defining
implementations via tasks which relate to a practice area for secure development.

10. API Security Impact
NIST 800-218 v1.1 isn’t the end all
be all but it is a starting point to
ensuring mature development
standards are maintained within
your organization.
TRUST is built by being able to
attest to your defined policies
(and yes artifacts will likely be
required).
SECURED from the get-go by
enforcing SSDF policies within
your organization.
TRAINING is a huge part in the
success of any new imitative and
the SSDF implementations should
include continuous training
activities.

11. Most Importantly
In addition to risk, factors such
as cost, feasibility,
and applicability should be
considered when deciding which
SSDF practices to use and how
much time and resources to
devote to each practice.