DevSecOps Culture Implementation for Building IntelliBroń [Part: 1]

Written by Muhammad Akmal.

As in any typical product development phase, IntelliBron began with prototyping. It started with ideation, followed by vision, and then moved on to implementation. It started with one person and gradually grew to include several early team members within a few months. When multiple people are involved, a framework must be used as the agreed upon guidance.

Despite having previous consulting experience in aiding customers to transition from 'conventional' to DevOps and DevSecOps, I am conscious that implementing DevSecOps is not a simple copy-paste process. The software or product development process is dynamic, with numerous key parameters that differentiate one implementation from another, ranging from the environment, culture, processes, technologies, people, business model, target customers, and so on.

Here's the snippet of our initial (version 0) high-level infrastructure architecture that become foundation to formulate our own DevSecOps implementation.

Therefore, we have to formulate our own DevSecOps models that are suitable for our product development requirements. I hope that what we share in this series will provide insight to those who wish to transition their development from traditional methods to DevOps and DevSecOps.

Why DevOps?

Today, IT products and services have become commodities that cannot be separated from daily human needs. They serve educational and working purposes as well as entertainment for users from varying age backgrounds, socioeconomic statuses, and age groups. Regardless of their type or purpose, IT products and services undergo lengthy development activities that employ complex resources including people, processes, and technologies. To effectively coordinate numerous resources, experts design methodologies specifically for the development process.

Let us investigate how software/system development life cycle (SDLC) methodology adapts to meet the growing demand for continuous improvement in the development process.

Waterfall Methodology

As the name suggests, the processes in the waterfall method flow sequentially from planning to operation, as shown in the diagram below.

During the planning phase, products or services are assessed for their ability to achieve specific goals based on various requirements, with the aim of delivering the desired outcome. Upon confirmation of the plan, the product or service is designed in the designated “design” phase, which can be divided into physical and logical design. Subsequently, the code writing process begins in the “code” phase, followed by several testing processes during the “test” phase to ensure that the code functions as intended. Once the code passes all tests, it transitions from the "kitchen" to the "dining room" through the deployment process ("deploy" phase). Finally, the code takes the form of products or services that run in the production environment and are used by the users ("operate" phase).

This process appears to be well-structured and orderly. However, some drawbacks arise over time. The waterfall method enforces a sequential process, but any unclear plans or changes in business needs will force the process to restart from the beginning. Imagine that the process was at the "code" phase, but a sudden change in plans caused a redesign. Whether you like it or not, the code must be rewritten, otherwise the final result will not meet the goals. This condition causes the delivery time to be extended. Longer delivery times incur higher production costs, as more man-hours need to be paid for. Longer delivery times incur higher production costs, as more man-hours need to be paid for. Increased costs also result in distractions from feasibility studies regarding the necessity of building certain products or services.

There is no justification for producing a product or service whose value is lower than the cost. These advantages lead us to adopt a newer and better approach known as the "agile method", which was developed to address any concerns with the traditional Waterfall method.

Agile Methodology

This methodology aims to solve the issues caused by unclear or last-minute changes to plans in traditional methods. Instead of forcing a linear process, the agile approach encourages a back-and-forth style through the creation of prototypes. This allows for immediate showcasing of products or services to users, making it possible to receive feedback quickly. This allows for immediate showcasing of products or services to users, making it possible to receive feedback quickly. This allows for immediate showcasing of products or services to users, making it possible to receive feedback quickly.

If the feedback shows that the products or services do not meet the users' needs, there is no issue in reverting back to the beginning, rebuilding the prototype and re-showcasing it to the users. On the contrary, if feedback is positive, further prototypes can be built through cycles until they form perfect products and services that satisfy users' needs. The agile method process can be illustrated as shown below.

During the "preparation" phase, initial requirements are gathered and converted into multiple features. Each feature will have several tasks that are picked for processing in a cycle called a sprint. A sprint will consist of activities such as design, code, test, and deployment, all aimed at producing a prototype that can be delivered to users as soon as possible. Work progress will be reviewed twice a day - in the early morning and at the end of the day. Additionally, a sprint review agenda will be scheduled whenever a sprint concludes. This method has effectively resolved issues related to unclear or modified plans in the waterfall method.

However, some problems persist as shown in the image below.

Due to its agility, products or services are often tested only on the developer's workstation, not in production. This leads to a situation where the developer team and the operations team work in silos, resulting in a communication gap between the two teams.

For example, when a developer submits a product for deployment, it may not be properly vetted by the operations team. If a failure occurs on the production servers, the operations team may not be aware of it and will simply send the product back to the development team, who may be working on other projects at the time. This delay will cause longer delivery times, despite the fact that it is the same issue found in the Waterfall method.

As previously mentioned, longer delivery times will affect production costs, etc. It appears that there is a need for a better method to address these issues.

DevOps Methodology

The development-operations, or DevOps, method is designed to bridge the gap between development and operations teams, enhancing the effectiveness of the agile method. The method is illustrated in the image below.

The DevOps approach fosters collaborative and continuous processes. The DevOps approach fosters collaborative and continuous processes. This strategy dismantles barriers between teams, allowing for seamless teamwork. While development phases follow similar sequences, continuous integration and deployment, supported by automation, are crucial elements that set DevOps apart from traditional approaches. Surely, the delivery time can be reduced by fixing any production environment failures and re-deploying them promptly. This approach enables problems to be addressed promptly using the agile methodology.

Nonetheless, like previous methods, this approach also has its own drawbacks. However, the focus this time is on the security aspect.

Why DevSecOps?

As the organisation employs DevOps methodology for their SDLC and places increased focus on security testing, the classic issue of delivery time has arisen once more. Let us see picture below.

In DevOps, a security test is conducted just before the deployment process. If any vulnerabilities are discovered, the process is sent back to the team in charge of fixing them.

However, the security test can become an obstacle to the product delivery process. This situation can put the organization in a dilemma. On the one hand, the organization may strictly prohibit any deployment to production if the security test is not passed, even if it means longer delivery times, to ensure its own security. While other situations may tempt organizations to ignore security to minimize the risk of late product delivery, this can introduce the risk of producing vulnerable products in the meantime.

Organizations surely demand a win-win solution to this dilemma. This is where another newer and better method called Development-Security-Operations or DevSecOps comes into play. Please look at the picture below first.

With DevSecOps, security is introduced from the very first step of the development process. It places emphasis on the principle that everyone is responsible for security. By adopting this approach, teams are able to detect vulnerabilities throughout the development and delivery process, thanks to the "shift security to the left" approach. Empowered by automated continuous integration and deployment/delivery, security tests can be run smoothly. This enables organisations to achieve a secure and on-time-delivered product. Later in this guidance, there will be a more detailed explanation about the DevSecOps method.

Segregation of Environment

In the production of products or services, there are two primary processes: development and deployment. Each process comprises one or more environments, as illustrated below.

The development process is performed by a team consisting of one or more analysts, designers, coders, and testers. They work in a 'Pre-Dev' environment, carrying out activities such as planning, design, coding, and testing. While there is a deployment process involved, it is not interchangeable with deployment in other activities. An actual DevOps professional is involved in this process for setting up automation for the first time and maintaining it on an as-needed basis. This environment has its own distinct code repository separated from others.

The deployment process is carried out by a team composed of a development lead, a DevOps team, an infrastructure team, a release manager, a tester, an internal user, a change manager, and a board of management. The release is first introduced in the "Development" environment and then rolled out to the "Staging" environment before it reaches the "Production" environment and is made available to users. Common activities in this process include merging code, building images, deploying images, testing, analyzing, and releasing through the change management process.

It is necessary to segregate these environments in accordance with security standards, such as ISO/IEC 27001:2022, to ensure that products or services are produced using proper processes, and that the Staging and Production Environments meet all business requirements in terms of functionality, reliability, availability, resilience, and security. In the next section, we will delve deeper into each of these two processes.

We will continue with the second part in the next series, starting with Development Process (Level 0 and Level 1)