{"id":111342,"date":"2025-02-27T16:19:53","date_gmt":"2025-02-27T14:19:53","guid":{"rendered":"https:\/\/www.dev.piisku.fi\/?post_type=blog_posts&p=111342"},"modified":"2025-05-27T14:42:52","modified_gmt":"2025-05-27T11:42:52","slug":"part-3-navigating-security-challenges-the-secure-software-development-lifecycle-meets-devops","status":"publish","type":"blog_posts","link":"https:\/\/www.dev.piisku.fi\/fi\/blog_posts\/part-3-navigating-security-challenges-the-secure-software-development-lifecycle-meets-devops","title":{"rendered":"PART 3 \u2013 Navigating security challenges: The Secure Software Development Lifecycle meets DevOps"},"content":{"rendered":"

In part 3 of this series, we\u2019ll describe the post-implementation phases of a secure software development lifecycle, or SSDLC.<\/p>\n<\/div>

Release and deployment<\/strong><\/span><\/h2><\/div>
<\/div><\/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>

At this phase of the release, the artefacts that are ready are deployed into the production environment. In DevOps, this phase is often called the \u201cpackage and release\u201d phase. The aim of this phase is to ensure the security and integrity of deliverables are not compromised during deployment. The released artefacts are integrity checked to ensure the pipeline has remained intact throughout the release process. If the release is a first-time launch of a new system, this is the last point at which rigorous acceptance testing, including security tests, can be performed.<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

The deployment process should be planned and implemented in a way that allows minimum possibility of human error. Infrastructure as code, or IaC, supports this ideology, but there are a wide range of configurations\u2014platform, cloud, application, and database\u2014all of which should be tested and verified from a security perspective.<\/p>\n

The release and deployment phase contains processes and procedures for preparing the delivered system or system functionalities for the centralized logging system. The log delivery mechanism and log monitoring process are activated, and the possible Security Operations Center, or SOC, begins actively monitoring the deployed system.<\/p>\n

Implementation, testing and verification, and release and deployment are heavily supported by an automated CI\/CD pipeline.<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

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

Applications require continued attention after they\u2019re put into production. Maintenance can be viewed as part of the development cycle; it is typically called the \u201cmonitor\u201d phase in DevOps. This may seem easy enough if application development continues after production deployment, but what happens to maintenance of the deployed application if the team moves on to the next project?<\/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 dynamic nature of the threat landscape and the continuous emergence of new vulnerabilities require active monitoring of the deployed application combined with vulnerability management processes. These processes should be documented and operational, with comprehensive procedures and methodologies for effectively monitoring vulnerabilities across all layers of the technological stack and implementing processes to respond to emerging threats. The SOC (Security Operations Center) monitors the system during the maintenance phase, while the responsible party updates the stack (development, cloud, platform, and so on). The responsibilities of the various parties are defined during previous SSDLC phases.<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>

Feedback loops<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

There\u2019s a good chance your organization’s development cycle already includes continuous improvement processes built into it. This phase may just be a matter of tweaking existing feedback processes by adding feedback from the required security controls as designed, implemented, and tested. Feedback can be automatically or manually requested or gathered from multiple sources: during project meetings, using agile methodologies, from static analysis reports, and so on.<\/p>\n<\/div>

When the lifecycle ends<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

An application eventually reaches the end of its lifecycle. It is critical to proactively plan for secure closure of a service\u2014ideally when establishing data handling requirements during the relevant design phase. What happens to data when the service is shut down? If data needs to be transferred or archived, how is this managed? The characteristics of the data and the organization’s data handling procedures inform this process.<\/p>\n<\/div>

Not all systems are equal<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

There are various methods for implementing security during system development and operation. However, not all systems involve data that necessitates the highest level of security.\u00a0 It is important to assess the right level of security and the relevant controls using a risk-based approach in adherence to the organization\u2019s risk-management processes.<\/p>\n<\/div>

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

Bringing robust security to daily working habits is rarely straightforward, nor does it always come easily. Leveraging Secure by Design principles during development while maintaining speed and agility may seem daunting. Acknowledging the challenges involved and dedicating the necessary resources, time, and effort can allow an organization to foster a culture of security and ultimately build more resilient and secure systems. This never-ending journey requires collaboration, ongoing education, and a commitment to prioritizing security throughout the entire DevSecOps lifecycle, without forgetting other important security aspects, such as physical security and workstation security.<\/p>\n

And in the long run, the rewards of enhanced security, reduced risk, and increased customer trust are well worth resources dedicated to DevSecOps. After all, you cannot outsource responsibility for security.<\/p>\n

Furthermore, automation, artificial Intelligence, machine learning, and large language models, or LLMs, are opening new ways of incorporating security into the development lifecycle\u2014but that\u2019s a subject for another blog.<\/p>\n<\/div>

General secure development resources<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

https:\/\/www.microsoft.com\/en-us\/securityengineering\/sdl<\/a><\/p>\n

https:\/\/owasp.org\/www-pdf-archive\/Jim_Manico_(Hamburg)_-_Securiing_the_SDLC.pdf<\/a><\/p>\n<\/div>

Requirements resources<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

https:\/\/owasp.org\/www-project-application-security-verification-standard\/<\/a><\/p>\n

https:\/\/csrc.nist.gov\/pubs\/sp\/800\/53\/a\/r5\/final<\/a><\/p>\n<\/div>

Design and implementation resources<\/strong><\/span><\/h2><\/div>
<\/div><\/div>

https:\/\/owasp.org\/www-project-proactive-controls\/<\/a><\/p>\n

https:\/\/cheatsheetseries.owasp.org\/index.html<\/a><\/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>