SBN

Addressing Security and Compliance Risk in the SDLC

We review the different compliance standards that apply to the software development life cycle (SDLC) along with best practices for meeting them.

Photo by Tolga Ulkan on Unsplash

It’s no surprise that developers are being asked to become security people. According to the 2021 Verizon Data Breach Investigation Report, basic web application attacks were the second most-used patterns found for breaches and incidents. As legislative bodies and industry standards organizations look to protect data, they increasingly look to the developers. This means that DevOps teams need to focus on both securing applications and documenting their actions to prove compliance. With automation, building security and compliance into the software development life cycle (SDLC) doesn’t need to be a chore.

What are some compliance mandates that apply to the SDLC?

Digital transformation and the increased focus on supply chain attacks is changing how governing bodies — federal, state, and industry — view compliance. Nearly every new mandate released incorporates third-party vendor management, often with a focus on web application security. Sometimes, they even focus on internally developed application development practices.

Cybersecurity Maturity Model Certification (CMMC)

Although CMMC currently applies only to the Defense Industrial Base (DIB), it can potentially become a more widely adopted compliance requirement across the federal space. In fact, the Department of Defense (DoD) announced in late 2020 that it would be requiring CMMC compliance as part of contracts with other agencies.

Since CMMC’s primary focus is to protect the DoD supply chain, it needs to take software development practices into account, and it does.

Organizations that need to meet CMMC Level 3 certification requirements, need to comply with section CA.3.162 which states that they must:

Employ a security assessment of enterprise software that has been developed internally, for internal use, and that has been organizationally defined as an area of risk.

As part of the assessment objectives, CMMC assessors will need to determine if:

[a] the organization reviews internally developed software for risks;

[b] for the code that is defined as an area of risk, the organization has documented the security assessment process which may include one or more of the following: manual code review, static analysis, and/or dynamic analysis;

[c] the organization has the ability to demonstrate their security assessment process; and

[d] the security assessment process is integrated with the change management process.

Payment Card Industry Data Security Standard (PCI DSS)

Organizations that collect, process, transmit, or store sensitive cardholder data also find themselves needing to meet stringent compliance mandates. PCI DSS requires organizations to develop software applications securely, and it outlines ten different compliance requirements for developers.

For example, Requirement 6.3 states that organizations must:

Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:

  • In accordance with PCI DSS (for example, secure authentication and logging)
  • Based on industry standards and/or best practices.
  • Incorporating information security throughout the software development life cycle

Requirement 6.5 outlines ten types of application risks that developers need to mitigate:

  • Injection flaws
  • Buffer overflows
  • Insecure cryptographic storage
  • Insecure communications
  • Improper error handling
  • “High risk” vulnerability detection
  • Cross-site scripting (XSS)
  • Improper access control
  • Cross-site request forgery (CSRF)
  • Broken authentication and session management

Health Insurance Portability and Accountability Act (HIPAA)

Although HIPAA itself doesn’t contain a reference to SDLC, the National Institute of Standards and Technology (NIST) Special Publication (SP) 800–66 “An Introductory Resource Guide for Implementing the HIPAA Security Rule” does mention it. NIST SP 800–66 is currently in the process of being revised.

In the current iteration of NIST SP 800–66, it sends you to the NIST 800–53 “Security and Privacy Controls for Information Systems and Organizations” which notes under the Discussion of Control SA-8 “Security and Privacy Engineering Principles” that examples of system security engineering principles include “ensuring that developers are trained on how to build secure software.”

Additionally, Control SA-15 “Development Process, Standards, and Tools” that organizations should:

Require the developer of the system, system component, or system service to follow a documented development process that:

1. Explicitly addresses security and privacy requirements;

2. Identifies the standards and tools used in the development process;

3. Documents the specific tool options and tool configurations used in the development process;

4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development;

In the Discussion of control enhancements the NIST RMF explains that to reduce the attack surface, organizations should apply secure software development practices, reduce the amount of code that executes, and eliminate vulnerable application programming interfaces (APIs) that are vulnerable to attacks.

Center for Internet Security (CIS) Controls V.8

CIS Controls v.8 goes into a lot of depth around the secure SDLC process.

Under Control 16 “Application Software Security,” organizations need to:

Manage the security life cycle of in-house developed, hosted, or acquired software to prevent, detect, and remediate security weaknesses before they can impact the enterprise.

The CIS Controls then set out the following practices:

  • Establish and Maintain a Secure Application Development Process
  • Establish and Maintain a Process to Accept and Address Software Vulnerabilities
  • Perform Root Cause Analysis on Security Vulnerabilities
  • Establish and Manage an Inventory of Third-Party Software Components
  • Use Up-to-Date and Trusted Third-Party Software Components
  • Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities
  • Train Developers in Application Security Concepts and Secure Coding
  • Apply Secure Design Principles in Application Architectures
  • Implement Code-Level Security Checks

Building the Foundation of a Secure and Compliant SDLC

Securing applications during the development process is rapidly becoming a business-critical practice. However, many developers worry that application security and meeting service level agreements (SLAs) conflict with each other. The reality is that to maintain a competitive, compliant edge in the market, businesses need to find ways to maintain a robust application security program.

Track Application Dependencies

A look at the recent Executive Order on Improving the Nation’s Cybersecurity’s inclusion of the Software Bill of Materials highlights the heightened role that tracking dependencies plays in securing supply chains.

When tracking dependencies, some best practices include:

  • Focusing on individual features or use-cases
  • Using a dependency manager
  • Talking with all internal stakeholders involved in the application’s development, like architects, IT leadership, and developers

Engage in a Manual Code Review

Reviewing source code is fundamental to finding an application’s security weaknesses.

When performing a security code review, some best practices include:

  • Looking for vulnerabilities that target the application type
  • Reviewing for vulnerability indicators and signatures
  • Tracking data flows to identify common vulnerabilities
  • Searching for strings, keywords, and code patterns known to be indicators for vulnerabilities and misconfigurations
  • Search plain-text data sets for dangerous functions
  • Review potentially risky functions for reachability
  • Review user input locations for exploitable vulnerabilities that can act as entry points

Create a Repeatable, Documented Processes

Part of compliance is being able to prove that you can maintain your security posture. If you don’t have repeatable processes, you end up relying on internal, historical knowledge. Unfortunately, if the people who know what to do leave the organization, that experience leaves with them.

Some ways to embed application security into your application development processes include:

  • Building security into the pull request process
  • Setting practices for using security tools to validate manual reviews
  • Incorporating security checks as a release gate for deployment and software delivery
  • Implementing a software delivery model that includes security, functional, and performance sign-offs as a deployment condition

Use an Automated Code Analysis Solution

Managing all code reviews manually becomes time-consuming. Additionally, it increases the likelihood of human error risks.

Some automated tools that can help you streamline the code review process include:

  • Static Analysis Security Testing (SAST): identify vulnerable code patterns
  • Software Composition Analysis (SCA): scan code for CVEs found in an application’s dependencies
  • Secure Scorecards: automated “pass/fail” checks that provide risk scores

Securing Your Application’s Future by Leveraging Compliance

At the end of the day, compliance is nothing more than a way to prove that you double-checked your work. Just like in your elementary school math class, you should always go back and review what you’ve done to make sure you didn’t make mistakes that can cost you an A.

However, just like you moved from memorizing multiplication charts to using a graphing calculator as you matured in school, you can use automated tools like ShiftLeft CORE to mature your secure coding practices. Even better, ShiftLeft helps you automate redundant, manual compliance tasks so that you can secure your code and document your activities to “show your work” to the auditors.


Addressing Security and Compliance Risk in the SDLC was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by The ShiftLeft Team. Read the original post at: https://blog.shiftleft.io/addressing-security-and-compliance-risk-in-the-sdlc-a170f34f4c64?source=rss----86a4f941c7da---4