Earlier last month NIST released a draft copy of CyberSecurity White paper titled “Mitigating the risk of Software Vulnerabilities by adopting a Secure Software Development Framework [SSDF]” for comments. The paper highlights how few software development lifecycle [SDLC] models explicitly address software security in detail and it recommends a core set of high-level secure software development practices to be added to each SDLC implementation. The idea is that these core practices will help software producers reduce the number of vulnerabilities in released software. Also, software consumers need to consider security aspects in the software acquisition process. Thus, the audience of the paper is two-fold i.e. software producers and consumers alike.

The paper describes secure software development practices, wherein each practice has the following elements:

These practices are organized into four groups as:

In this blog we will review some of the key practices as below:

PO.3 – Implement a Supporting Toolchain 

NIST highlights the importance of using automation to reduce human effort required and improve the accuracy, consistency and comprehensiveness of security practice.

PW.1 – Take Security Requirements and Risk Information into Account during Software Design

This is a key aspect since security is typically an afterthought. The paper advocates the use of threat modeling, attack modeling, attack surface mapping and other forms of risk modeling.
ThreatWatch (TW) can help with threat modeling based on 3rd party components used.


PW.3 – Verify Third-party Software Complies with Security Requirements

This practice talks about reducing the risk associated with using acquired software modules and services, which are potential sources of additional vulnerabilities. This is a key aspect which is often overlooked by software producers. One of the tasks under PW.3 is as follows:

TW can help organizations in such assessments for commercial and open source third-party softwares alike.


PW.4 – Reuse existing, well-secured software when feasible instead of duplicating functionality

This may come across as a no-brainer to most, but some organizations still build their own libraries rather than leverage existing ones. This approach is strictly not recommended for softwares that implement security functionality such as cryptographic modules and protocols.

PW.8 – Test executable code to identify vulnerabilities and verify compliance with security requirements

The idea is to perform robust functional testing of security features before software is released.

PW.9 – Configure the software to have Secure Settings by default

The focus is to ensure that default installations of the software are secure by default.

RV.1 – Identify and confirm vulnerabilities on an ongoing basis

One of the tasks [RV.1.1] mentioned under this practice entails collection of information from consumers and public sources on potential vulnerabilities in the software and third-party components used in the software.

TW can be effectively used to gather vulnerability intel for third-party components used in the software and understand & assess their vulnerability posture.


Another key aspect that the paper calls out is for software consumers to take an informed decision during the software acquisition process. Let us consider two  examples below to better understand this aspect:

  1. An engineering team is working on creating the architecture blueprint for a large software solution and they need to decide which “Enterprise Service Bus” to use. There are multiple ESB solutions out there, some of which are commercial and others open source. Ofcourse the engineering team will consider multiple aspects while picking the right ESB solution like ease of use, scalability, modularity, development time, etc. One key aspect that is often overlooked is the software vulnerability one – how many open vulnerabilities are present in each ESB solution, what does the vulnerability trend look like, how quickly are vulnerability fixes made available, etc. By looking at the vulnerability intel from a solution such as TW, the engineering team can factor in the vulnerability aspects into the decision making process.
  2. An organization is looking at deploying a HTTP server for their needs. They need to decide on the right HTTP server based on their requirements, scalability, etc. A key aspect that is often overlooked is the vulnerability report and trend for the HTTP server options being considered. For example how many vulnerabilities were reported in the last 30-60-90 days, how soon are the vulnerabilities addressed, are remediations provided to circumvent the vulnerabilities before a patch is made available, etc.

Organization needs to look at the vulnerability aspects of a software while making a purchasing or adoption decision for new software.

For more details on how TW can be leveraged by your organization for tracking vulnerabilities in 3rd party software as part of your DevOps CI/CD process, reach to us at info@threatwatch.io

Leave a Reply

Your email address will not be published. Required fields are marked *