Software development is akin to building a beautiful work of art. It requires focus, expertise, and talent. The software development process needs to be nurtured with the right support, but is it? The important point to understand here is that no matter how artful and deliciously well crafted the Software Development Lifecycle may be, it has to contend with reality. What reality are we referring to?

Let us begin the journey together by recognizing how brutally true this quote is – “Everyone has a plan until they get punched in the mouth.” – Mike Tyson.

Corporate, for-profit organizations, are alive to make money, for their shareholders. Revenue matters, it really matters – for companies of all sizes. Shipping products to customers, making them happy, collecting credit card transfers, and staying on a hyper-growth black curve is what corporate boards have been chanting like a mantra for ages. In these few statements nowhere did I mention – code quality, vulnerability resolution, or anything to that effect. Why? The focus for a business is primarily revenue, profit, customer acquisition, growth. In this mad dash to grow at any cost – code quality has often taken a back seat.

Interestingly, things have been changing over the last decade and will continue to change – and – faster. Companies and technology teams have started to fine-tune the art of balancing delivery timelines with security, code quality to some extent. We are still far away from the Elysian plains where code quality, feature velocity, and security all roll in a bed of flowers like good brethren. Yet, one has to admit that companies have started taking seriously aspects of code quality, best practices of software development opined over years by academics and practitioners alike. Yes, it is true that we now have quite good SDLC standards, practices, security reviews, pair programming sessions, and more available to us as the tools of the trade. The question then is – Are we diligently employing these tools every time product development is kicked off?

No. The answer is no. A resounding no. Disheartening as it may be there is a silver lining here. Software development as a process continues to improve leading to fewer bugs, code quality issues per KLOC (thousand lines of code). Then what is the point of this article – to highlight the obvious? Of course not – In this article, we will discuss what the newest guidance for tackling this issue from an interesting perspective talks about. The reason why it is pertinent to talk about it at this time is because of the focus of the guidance – What should software vendors do at a minimum to make sure their software code is well constructed, tested, and secure. This is especially important in light of the recent events all through 2021 and 2022, which strengthens the case for supply chain security.

We are going to talk about NISTIR 8397, based on the guidance from Executive order 14028 issued by the current US administration. What does this guidance talk about, why is it important, and much more beyond these basic questions? The document in question describes eleven recommendations for software verification techniques as well as provides supplemental information about the techniques and references for further information. It recommends the following techniques:

  • Threat modeling to look for design-level security issues
  • Automated testing for consistency and to minimize human effort
  • Static code scanning to look for top bugs
  • Heuristic tools to look for possible hardcoded secrets
  • Use of built-in checks and protections
  • “Black box” test cases
  • Code-based structural test cases
  • Historical test cases
  • Fuzzing
  • Web app scanners, if applicable
  • Address included code (libraries, packages, services)

These areas of focus are important for companies to make sure that the software being developed follows best practices, which lead to good code quality, which in turn reduces the attack surface due to insecure code or 3rd party component usage. One of the main areas to drilling down on is the focus for automating a majority of these areas of focus. As an example – automated scanners that provide software component analysis (SCA) that help with static scanning, forming a software bill of materials (SBOM), API cataloging, analysis of vendor information – provide immense value and do not create choke points for the SDLC processes in companies.

According to the guidance, organizations should consider risk in terms of context, – what are the vulnerabilities, and how applicable are they to your situation. There are in general 3 categories of risk to be considered:

  1. Risk related to your environment.
  2. Risk related to the data you store and process.
  3. What is the source of the data and information that you store.

Recursively checking dependencies such as libraries, packages, and services to assure equivocal security to the application is a major key to mitigating risk related to the software supply chain. Correcting the uncovered bugs and learning from the found vulnerabilities is important to improving the security of the software.

For more information on how your organization can implement these standards in place please feel free to contact us at Riscosity, +1-888-RISCOSI, or book a free demo with us.