OWASP Developer Guide

Secure Development and Integration

Home > Release-pt-br > foundations > secure development

2.2 Secure development and integration

Secure development is described in the OWASP Software Assurance Maturity Model (SAMM) Design, Implementation and Verification business functions.

Prelude

The best introduction to practical secure software development is the OWASP Application Security Fragmentation article :

Or how I worried less and stood on the shoulders of giants. - Spyros Gasteratos, Elie Saad

Much of the material in this section is drawn from this OWASP Integration Standards project.

Overview

Almost all modern software is developed in an iterative manner passing through phase to phase, such as identifying customer requirements, implementation and test. These phases are revisited in a cyclic manner throughout the lifetime of the application. A notional Software Development LifeCycle (SDLC) is shown below, in practice there may be more or less phases according to the processes adopted by the organization.

SDLC Lifecycle

With the increasing number and sophistication of exploits against almost every application or business system, most companies have adopted a secure Software Development LifeCycle (SDLC). The secure SDLC should never be a separate lifecycle from an existing software development lifecycle, it must always be the same development lifecycle as before but with security actions built into each phase, otherwise security actions may well be set aside by busy development teams. Note that although the Secure SDLC could be written as ‘SSDLC’ it is almost always written as ‘SDLC’.

DevOps integrates and automates many of the SDLC phases and implements Continuous Integration (CI) and Continuous Delivery/Deployment (CD) pipelines to provide much of the SDLC automation.

DevOps and pipelines have been successfully exploited with serious large scale consequences and so, in a similar manner to the SDLC, much of the DevOps actions have also had security built in to them. Secure DevOps, or DevSecOps, builds security practices into the DevOps activities to guard against attack and to provide the SDLC with automated security testing.

Examples of how DevSecOps is ‘building security in’ is the provision of Interactive, Static and Dynamic Application Security Testing (IAST, SAST & DAST) and implementing supply chain security, and there are many other security activities that can be applied. Refer to the CI/CD Security Cheat Sheet for the latest DevSecOps security controls.

Secure development lifecycle

Referring to the OWASP Application Security Wayfinder development cycle there are four iterative phases during application development: Requirements, Design, Implementation and Verification. The other phases are done less iteratively in the development cycle but these form an equally important part of the SDLC: Gap Analysis, Metrics, Operation and Training & Culture Building.

All of these phases of the SDLC should have security activities built into them, rather than done as separate activities. If security is built into these phases then the overhead becomes much less and the resistance from the development teams decreases. The goal is for the secure SDLC to become as familiar a process as before, with the development teams taking ownership of the security activities within each phase.

There are many OWASP tools and resources to help build security into the SDLC.

  • Requirements: this phase determines the functional, non-functional and security requirements for the application. Requirements should be revisited periodically and checked for completeness and validity, and it is worth considering various OWASP tools to help with this;

  • Design: it is important to design security into the application - it is never too late to do this but the earlier the better and easier to do. OWASP provides two tools, Pythonic Threat Modeling and Threat Dragon, for threat modeling along with security gamification using Cornucopia.

  • Implementation: the OWASP Top 10 Proactive Controls project states that they are “the most important control and control categories that every architect and developer should absolutely, 100% include in every project” and this is certainly good advice. Implementing these controls can provide a high degree of confidence that the application or system will be reasonably secure. OWASP provides two libraries that can be incorporated in web applications, the Enterprise Security API (ESAPI) security control library and CSRFGuard to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks, that help implement these proactive controls. In addition the OWASP Cheat Sheet Series is a valuable source of information and advice on all aspects of applications security.

  • Verification: OWASP provides a relatively large number of projects that help with testing and verification. This is the subject of a section in this Developer Guide, and the projects are listed at the end of this section.

  • Training: development teams continually need security training. Although not part of the inner SDLC iterative loop training should still be factored into the project lifecycle. OWASP provides many training environments and materials - see the list at the end of this section.

  • Culture Building: a good security culture within a business organization will help greatly in keeping the applications and systems secure. There are many activities that all add up to create the security culture, the OWASP Security Culture project goes into more detail on these activities, and a good Security Champion program within the business is foundational to a good security posture. The OWASP Security Champions Guide provides guidance and material to create security champions within the development teams - ideally every team should have a security champion that has a special interest in security and has received further training, enabling the team to build security in.

  • Operations: the OWASP DevSecOps Guideline explains how to best implement a secure pipeline, using best practices and automation tools to help ‘shift-left’ security issues. Refer to the DevSecOps Guideline for more information on any of the topics within DevSecOps and in particular sections on Operations.

  • Supply chain: attacks that leverage the supply chain can be devastating and there have been several high profile of products being successfully exploited. A Software Bill of Materials (SBOM) is the first step in avoiding these attacks and it is well worth using the OWASP CycloneDX full-stack Bill of Materials (BOM) standard for risk reduction in the supply chain. In addition the OWASP Dependency-Track project is a Continuous SBOM Analysis Platform which can help prevent these supply chain exploits by providing control of the SBOM.

  • Third party dependencies: keeping track of what third party libraries are included in the application, and what vulnerabilities they have, is easily automated. Many public repositories such as github and gitlab offer this service along with some commercial vendors. OWASP provides the Dependency-Check Software Composition Analysis (SCA) tool to track external libraries.

  • Application security testing: there are various types of security testing that can be automated on pull-request, merge or nightlies - or indeed manually but they are most powerful when automated. Commonly there is Static Application Security Testing (SAST), which analyses the code without running it, and Dynamic Application Security Testing (DAST), which applies input to the application while running it in a sandbox or other isolated environments. Interactive Application Security Testing (IAST) is designed to be run manually as well as being automated, and provides instant feedback on the tests as they are run.

Further reading from OWASP

OWASP verification projects

OWASP training projects

OWASP resources

The OWASP Developer Guide is a community effort; if there is something that needs changing then submit an issue or edit on GitHub.

Watch Star