{"id":111344,"date":"2024-11-20T11:12:20","date_gmt":"2024-11-20T09:12:20","guid":{"rendered":"https:\/\/www.dev.piisku.fi\/?post_type=blog_posts&p=111344"},"modified":"2025-05-27T14:48:34","modified_gmt":"2025-05-27T11:48:34","slug":"part-1-navigating-security-challenges-the-secure-software-development-lifecycle-meets-devops","status":"publish","type":"blog_posts","link":"https:\/\/www.dev.piisku.fi\/en\/blog_posts\/part-1-navigating-security-challenges-the-secure-software-development-lifecycle-meets-devops","title":{"rendered":"PART 1 \u2013 Navigating security challenges: The Secure Software Development Lifecycle meets DevOps"},"content":{"rendered":"

Mapping the phases of the software development lifecycle to the secure development lifecycle<\/span><\/h2><\/div>
<\/div><\/div>

Before we dive into the phases of the secure software development lifecycle, or SSDLC, it\u2019s important to understand how the phases of this lifecycle vary from those of the continuous integration and continuous delivery (CI\/CD) pipeline.<\/p>\n

The model presented here is one possible phasing of a secure development lifecycle. Making IT operations part of the equation results in a broader DevSecOps strategy for implementing and operating applications and services.<\/p>\n<\/div>

Planning and requirements<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

Prior to the first full iteration of the development lifecycle, the organization needs to have a solid foundation that supports SSDLC efforts. Staff ought to have awareness of security perspectives in general and understand how those perspectives apply in upcoming projects and their roles within those projects. Before the actual development cycle kicks off, requirements should be gathered and basic building blocks defined for each upcoming project. This means establishing guiding principles, delineating a framework for working methods, and laying the groundwork for architectural decisions.<\/p>\n

The sources of requirements can be internal or external. One internal source of requirements is the organization’s risk-management process. Depending on the application and the data managed by it, external requirements may be laid out in relevant legislation and specific customer security requirements. The guiding principles of secure development, including the necessary security-informed quality gates, should be established and stated during the planning phase.<\/p>\n

Security requirements need defining for architecture, authentication, validation, cryptography, key management,\u00a0error handling, logging, and every other element and function of the service being designed. More information on security requirements can be found, for example, in the Open Worldwide Application Security Project (OWASP) \u2019s Application Security Verification Standard (ASVS) or the National Institute of Standards and Technology\u2019s special publication (NIST) SP 800-53 (links are provided in this blog\u2019s resources section).<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

It\u2019s usually wise to begin disaster recovery, or DR, planning, as early as possible. Specific requirements for recovering the system within a defined timeframe and restoring it to a specific point in time are typically established to ensure business continuity. The requirements-gathering phase is not too early to begin making scenario-based recovery plans. Plans must also include scenarios for continuing development if the disaster occurs before the production phase. In general, DR planning ought to be fully implemented and tested before production usage starts.<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div>

\"\"<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

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\u2019s iteration activities. Work unit iterations don\u2019t 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.<\/p>\n

The planning and requirements phases are the time for a quick reality check. Ask yourself: \u201cHave we thought about security risks alongside other project risks?\u201d<\/p>\n<\/div>

Design<\/span><\/h2><\/div>
<\/div><\/div>

The security requirements derived from the planning phase are then carried over into the system design phase, or the \u201cplan\u201d phase as it\u2019s 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\u2019s 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.<\/p>\n

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.<\/p>\n<\/div>

Implementation<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

During this phase, implementation processes and procedures are put into practice. In DevOps, this phase is usually called the \u201ccreate\u201d phase. The implementation of requirements-based business functionalities and the implementation of security controls go hand in hand.<\/p>\n

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\u2019s there to implement?” The answer may be: what about the relevant automation?<\/p>\n

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.<\/p>\n

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\u2019s 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.<\/p>\n<\/div>

Testing and verification<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

Testing and verification\u2014in DevOps, often called the \u201cverify\u201d phase\u2014run 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\u2019t 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 \u201cmajor releases,\u201d as small pieces of implemented functionalities are constantly and automatically deployed directly into production. The suggestion here is to incorporate a \u201ctest as you go\u201d mentality, so security testing is built into the development cycle.<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

\"\"<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

During this phase, dynamic security testing is also conducted on the implemented deliverable, with the depth and scope of the testing scaled to the implemented functionality. In a security-oriented development team, the work unit cycle may include dynamic security testing of functionality side by side with peer review or the like. Do not mistake this for a full-fledged technical security test. It is not. A valid security audit should also be performed on the fully integrated system to ensure a cross-cut view of system security.<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

In Part 3 <\/strong>we’ll dive into the release and maintenance phases.<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

\n
\n<\/div>\n
\"\"<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

Jari Mannonen<\/strong> is working as the Head of Cyber Security Development at Piisku. He has over 20 years of consultancy experience in business-critical information technology and application architecture, with a focus on cybersecurity.<\/em><\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

\n
\n<\/div>\n

In this article, we have used AI-generated images.<\/em><\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>