PART 2 - Navigating security challenges: The Secure Software Development Lifecycle meets DevOps

The basic idea here is that DR be treated in isolation, as something to design, implement, and test right before production begins, but as a stream of tasks mapped to DevSecOps phases, just as any other tasks within the work unit’s iteration activities. Work unit iterations don’t always introduce changes to the DR plan or its implementation, but for instance the introduction of a new platform component may mean defining extra steps in an automated or manual recovery process.

The planning and requirements phases are the time for a quick reality check. Ask yourself: “Have we thought about security risks alongside other project risks?”

The security requirements derived from the planning phase are then carried over into the system design phase, or the “plan” phase as it’s typically referred to in DevOps. In this phase, security controls (access controls, including authenticating and authorization; input validation; encoding/decoding; logging and monitoring; target environment hardening; and so on) are designed in accordance with business, security, and architectural requirements. Those requirements guide the principles for developing and designing the application in question. The guidelines derived from the requirements should include the process for accepting open source or proprietary libraries used within the project. Good security hygiene means having a documented process for introducing new components during project implementation: the process’s steps should cover checking version/update, licence, support, and pricing schemes. If open-source components are used, the guidelines should also define which public repositories are trusted, if any.

In architecture and component design, threat modeling techniques should be leveraged to identify architecture-related risks. Threat modeling practices ought to involve the business perspective, reviewing user stories from a potential attacker’s point of view. These threat modeling sessions result in abuse use cases and negative test cases that inform system design.

During this phase, implementation processes and procedures are put into practice. In DevOps, this phase is usually called the “create” phase. The implementation of requirements-based business functionalities and the implementation of security controls go hand in hand.

Many implementation projects have shifted to an infrastructure as code (IaC) model, which means the infrastructure is coded during overall system development. This phase often includes implementation of planned disaster recovery (DR) functionalities and updates to the DR plan. In the case of IaC, you may be thinking: “what’s there to implement?” The answer may be: what about the relevant automation?

All elements of system components should be developed in accordance with the selected technology stack’s written guidelines and security documentation. Development practices should include clear documentation of the development process and guidelines for using source control, including branching, pull request/code reviews, deployment/release procedures, and possible GitOps processes. Code review consistency can be supported with a documented code review checklist.

Tooling and support processes play a crucial part in enabling agility in a security-enabled development lifecycle. The verification of secure implementation involves ensuring software composition analysis, including dependency analysis and static analysis tooling, as an integral part of development. The tooling may vary from IDE (Integrated Development Environment)-based tooling to (semi-)automatic tooling that relies on process automation within the CI/CD pipeline. It’s important to note that having the tooling in place is not enough to support secure development; the project must also have a documented and functioning process to support remediation of possible findings from the analyses.

Testing and verification—in DevOps, often called the “verify” phase—run alongside the implementation phase. From a security point of view, continued static analysis should be standard during testing and verification. In the past, when security considerations weren’t necessarily integrated into the development lifecycle, security testing typically took place shortly before version release. There was often a hurry to find security testers just a few weeks prior to scheduled testing. But leaving testing to the last means the release date might be compromised if a critical flaw is found. In today’s fast-paced world, postponing testing until the final stages of a major release is impractical. Some projects might not even involve any “major releases,” as small pieces of implemented functionalities are constantly and automatically deployed directly into production. The suggestion here is to incorporate a “test as you go” mentality, so security testing is built into the development cycle.

In Part 3 we’ll dive into the release and maintenance phases.

In this article, we have used AI-generated images.