Secure Development Lifecycle (SDL)

March 2023

Security vulnerabilities are widely recognized throughout the computer industry and by our customers who need assurance that the products they use are secure. To provide that assurance, NetApp has developed the Secure Development Lifecycle (SDL), a standard for product development that evaluates and responds to potential vulnerabilities.

NetApp’s SDL defines a rigorous process based on industry best practices and standards that product teams can follow to assess security and plan for the release of a secure product. The process begins with the first plans for a product, before a single line of code has been written, and extends through to monitoring products after they have been released.

The SDL implemented at NetApp is a defendable and repeatable 6-step process (illustrated in the following figure) that the teams who build NetApp products and services can follow. Throughout the course of product development, NetApp teams can execute this explicit and predefined set of activities to help ensure that the product is reliably secure. The SDL process enables NetApp to understand the risks the products present, as well as to evaluate the effectiveness of the product team’s compliance with the full SDL.

The product security group provides best practices for the SDL, procedures in support of it, and security expertise to the product teams. The product teams can implement the SDL processes and policies to deliver secure products. The SDL requires that all known vulnerabilities, including third-party component vulnerabilities, have been appropriately addressed.

The NetApp SDL process starts with building security awareness and expertise within our product teams through training and the appointment of security champions.

NetApp requires security training for personnel involved in product delivery. Security training includes education on current threats, secure development techniques, vulnerabilities, and methods for addressing security issues. The training is tailored to the role of trainees—product manager, developer, QA, and the like—to build awareness of product security and support for incorporating security practices into their work.

NetApp requires an annual security refresher to communicate the changes that inevitably occur in product security. NetApp also offers internal forums and access to commercial events to help individuals advance their security knowledge.

Security champions are security-minded professionals on NetApp product teams who promote secure development best practices and the SDL in their organization, while advancing the adoption and understanding of product security in general. Each champion receives in-depth security training, particularly exposure to security best practices, including the NetApp SDL. Although the primary objective is to embed security leadership in development teams, these champions also serve as key points of contact for the product security group as it monitors product team execution of the SDL.

The NetApp SDL process begins with a security assessment and release of the compliance and test plans. It follows with a thorough evaluation of product security issues and solutions, and validation that any identified vulnerabilities have been resolved. It ends with the communication or risk and monitoring activity through a Product Security Incident Response Team (PSIRT).

There are three touchpoints in this step in the SDL process: review of the product security baseline and EO 14028 requirements, threat modeling and mitigation, and review of the supply chain ecosystem. All of these are applied early in design development, before any code development or implementation.

Product security baseline and EO 14028 requirements review. The product security baseline is a minimum set of acceptable levels of security for all NetApp products. It is derived from security standards, such as ISO/IEC 27001, and contract commitments made to NetApp enterprise and government customers. The review process establishes a set of steps that product teams can follow to assess their product against each requirement; this includes review of the requirements defined under U.S. Executive Order 14028. They then form a plan to add any missing baseline functionality to the product.

Threat modeling and mitigation. Threat modeling is used to identify security flaws in a feature, component, or product early on. It enables product teams to consider in a structured way the security implications of their designs. Teams can then more effectively identify security vulnerabilities, determine the risk, and develop appropriate mitigations.

Trusted Supplier Program. Our goal with this program is to ensure that our ecosystem of strategic suppliers is able to consistently guarantee the highest level of security in the industry. Through it, NetApp evaluates strategic suppliers—both new and returning—who are involved in the development of NetApp products. The audit helps product teams validate that SDL activities are included in supplier development, manufacturing, and support processes. It also enables NetApp to determine whether the components that we source from them adhere to our standards.

There are two touchpoints in this step in the SDL process: establishing plans for both compliance and security testing.

SDL compliance plan. Through the compliance plan, product teams can define acceptable levels of security that they will execute for a specific release and identify how they will be held accountable for meeting these criteria. Establishing these levels early on helps the team understand risks associated with security issues, identify and fix security defects during development, and apply SDL standards throughout the project.

Security test plan. The security test plan integrates security test cases into the testing strategy and covers the many aspects of security, from authentication and authorization to securing data at rest or in transit. Creating and executing a security test plan includes fixing issues found can help ensure that potential security issues have been uncovered and adequately addressed before a product is released.

There are six touchpoints in this step of the SDL process: static and dynamic application security testing; secret scanning for potential occurrences of embedded secrets and keys; identifying security bugs in a secure code review; run-time scanning for known vulnerabilities, including through fuzzing; and scanning for vulnerabilities in third-party software.

Static Application Security Testing. Before compiling, product teams may use this test to scan source code to discover potential critical defects, security weaknesses, and vulnerabilities in the code. The test uses a set of hooks inside the build process of each project and a series of reporting tools, such as bug tracking and code review, to flag product defects. Developers are responsible for triaging and fixing any issues identified. This helps avoid problems in the release such as increased supportability challenges, memory corruption, system panics, or even remote code execution.

Secret scanning. Before releasing a product, NetApp uses the secret scanning tool to look for potential occurrences of embedded secrets and keys in source code. NetApp scans source files; project, build, and repository configuration files; binary and build package files; and repository access control lists.

Secure code review. Secure code review is a technique for identifying security bugs early in development, before submission to version control. It helps make sure that code does not suffer from any visible security weaknesses, such as specific code patterns articulated in the Common Weakness Enumeration (CWE) standard. Secure code review depends on insights gained from Static Application Security Testing and threat modeling.

Dynamic Application Security Testing. Product teams may identify run-time issues by performing this test on fully compiled software, thereby testing the security of integrated and running code in a test or staging environment. The scan activity involves configuring the web application being tested to facilitate scanning and then running the scan tool against the application. These scans can uncover a broad range of vulnerabilities, including input and output validation issues that might leave an application vulnerable to cross-site scripting or SQL injection. They can also help identify configuration errors and other specific problems with applications.

Vulnerability scanning. To identify common and known security vulnerabilities in NetApp products under development NetApp follows a standard process using signatures and configuration checks.

Fuzzing. To find security vulnerabilities, fuzzing is an automated runtime testing technique that introduces malformed or semi-malformed data into protocol interfaces to identify unintended results. The fuzzing tool that NetApp product teams use supports protocol-specific test suites that perform automated black box fuzzing. This testing can identify issues such as nonconforming RFCs. Fuzzing is often coupled with Dynamic Application Security Testing and is part of development sprints when testing code.

Third-party software scanning. Scanning third-party software (or software composition analysis) helps manage the security risk of using third-party components. It can create an inventory of open-source software and third-party components built into our products. The scan can flag components that may have legal and security issues, which may require corrective action before the product can be released. This allows known vulnerabilities to be quickly identified, and enables product teams to create a plan to address them. This scan can be conducted continually because newly discovered vulnerabilities may be reported at any time.

After product teams have identified and addressed security issues, they can validate the corrections that were implemented.

The communication of risk in the SDL process involves assessing, communicating, and addressing risks identified in prior touchpoints of the SDL. It may involve steps such as penetration testing, formal reporting, or the development of product-specific incident response procedures.

The Product Security Incident Response Team (PSIRT) is responsible for coordinating and managing investigations into vulnerabilities, whether reported publicly or from within the company, and the NetApp response, which includes public advisories related to investigation and mitigation. Product teams designate a point person from their team to coordinate with the PSIRT.