[Part 0] DevSecOps Introduction

Welcome to the DevSecOps introductory article (0–7 — spoiler). I would like to thank you in advance for reading it and your comments. I hope you will be satisfied after receiving some knowledge in this specialization and will continue to develop this direction in the future. This series of articles implies a basic understanding and knowledge of DevOps. As an author, I do not claim to have a final or conclusive expert opinion in this area.

These articles and practices are still in their infancy in the wild. This means that not all aspects are described properly and subsequently they will be supplemented more and more by going deeper into the processes of this topic in articles of the next generation.

The purpose of these articles is to increase knowledge in this area of application so that sooner or later you will need this knowledge, and therefore sooner or later this will be supported by various kinds of motivation for working in this area on the part of the customer.

Why now? In general, this practice existed initially when such a methodology as DevOps was formed. Given the current realities in the world, customers are eager to reduce irrelevant costs, while simultaneously introducing increasingly complex mechanisms to protect their business, both externally and internally.

All kinds of code leaks have become a frequent occurrence in recent years due to the uncontrolled use of auxiliary software during software development and delivery, which entails monetary and reputational losses. In general, this is a logical continuation of the DevOps methodology in the future.

What will you learn from this series of articles? You will learn to understand potential security problems in software development, analyze hidden areas in the infrastructure, evaluate and weigh decisions to improve or correct a particular situation, get acquainted with basic terminology and learn how to write correct reports for the customer, and also possibly consolidate the structure in personal practice secure approach to software delivery

Introduction

DevSecOps is a methodology that combines DevOps and security, allowing you to integrate security into every stage of software development and delivery. DevSecOps ensures that security is integrated into development and delivery from the start, rather than leaving it to the last stage before release.

The main goal of DevSecOps is to bridge the gap between development, operations, and security teams, which often work in silos and do not communicate in real-time. DevSecOps integrates security into every stage of the software development life cycle (SDLC), allowing you to identify and remediate security vulnerabilities and risks sooner, and deliver software faster.

Some engineers, having read a couple of articles on the Internet or watched a couple of videos on YouTube, naively believe that this knowledge will be enough to learn to think, analyze, and make decisions at the level of project architecture and software delivery. In other words, in order to learn the practices of implementing security in software delivery and understand critical points in the infrastructure, it is not enough to gain knowledge — it is important to learn to think analytically in this direction, which we will talk about in the next.

Concept of "Left Shift"

The “left shift” principle in DevSecOps means integrating security and testing into software development in the early stages of the SDLC to identify and remediate vulnerabilities and defects before they become problems in later stages.

Traditionally, testing and security were often seen as separate stages of software development, performed after the code was written. However, DevSecOps advocates believe that integrating security and testing at the very beginning of the software development process improves the quality and security of the application, as well as saves time and resources that could be spent on fixing defects later in the process.

In your work, one way or another, you have encountered similar things, but the problem is that this knowledge is different for different projects and technologies and has its own approach to dealing with various kinds of problems. This knowledge is poorly structured because some projects don’t think about tracking or using it at all. They prefer to pay money to third-party companies in the hope that these third-party companies will cover the full range of potential issues.

As practice and statistics show, a security audit is not very similar to the practices of introducing security into development, if only because these are two different approaches and companies care more about the external perimeter of security than about the internal one, if in general everything inside is not built on trust.

DevSecOps Building Blocks

DevSecOps consists of several fundamental blocks that ensure security at every stage of the software development lifecycle:

• Security development: includes early security integration into the development process, security integration into version control systems, and automated security checks.
• Security testing: includes vulnerability testing, static code analysis, penetration testing, and functional testing.
• Security integration: includes security integration into CI/CD pipelines, automated security checks, and the use of security monitoring tools.
• Security operations: includes security measures in the production environment, security monitoring and analysis, vulnerability management, and security incident management.
• Security culture: includes security awareness training and education for all participants in the development process, knowledge sharing, and collaborative decision-making on security issues.

A few words…

What happens in the end? DevSecOps is the practice of taking into account the requirements of the security engineer, developers, and, of course, the requirements for software delivery from the product owner or the team as a whole — where there were two chairs, there are now three. In other words, this is the provision of tools or techniques for monitoring and preventing potential problems, improving the infrastructure, regularly refactoring access, and controlling sensitive information, such as environmental secrets or any other sensitive information.

The task of a security engineer is to solve current problems and put forward requirements and instructions to different categories of engineers on what to do in a given situation. The objectives of DevSecOps are to automate the software to prevent potential problems at various stages of development, delivery, and operation, and improve the current infrastructure based on requirements.
Sometimes there is no security engineer on the project, in which case your task will be to introduce him from the side of DevOps practitioners — this is a difficult task, but subsequently, it increases your knowledge and ability to work with such things significantly.

This also applies to the meaningful use of this or that technology with an understanding of all the pros and cons of this approach. Very often, customers use the concept — it has always worked — well, okay, but there is one nuance: certain techniques, technologies, and application solutions have an outdated approach or they lack primitive protective functions.

In general, DevSecOps first evaluates the current state of affairs through analytics and compiling a table of possible risks in order to further update priorities and deadlines because It is important to be able to determine deadlines.

Write your opinions in the comments.
What do you think about this?

Best Regards,
Alex Lahutsin