DevSecOps: Part 1
DevOps series:
Docker and Containers: Part1 Overview
Docker and Containers: Part 2 in practice
Docker and containers: Part3 Microservices and Docker compose
Orchestration of the containers: Part 1
Orchestration of the containers: Part 2 Deploying at scale a containerized 3-tier Web Application
Orchestration of the containers: Part3 Enhancing the Kubernetes cluster
CI/CD Pipelines: Part 2 (GitHub Actions in Practice)
Traditional security is in crisis
Well , talking about security in software remains one of the fundamental topics and one of the most important aspects we should take care of.However security is facing some serious problems nowadays due to how it is managed within companies. It has encountered the same problem as development and operational where we let the security neglected at the end which creates consequently a lot of problems like working with some dependencies that have a lot of vulnerabilities while developing and so on…This is something unacceptable especially in a period of time where hackers have become more aware of the weaknesses of the software.
The source code of the repository created during the demo is here: devops-project.
Supply Chain Security
We can define Devsecops (supply chain security) as an extension of Devops where we take into account the security aspect. It is a way to deliver secure software rapidly, frequently and reliably.
Before the emergence of DevSecOps, security was often an afterthought in software development, addressed only at the end of the cycle. However, with DevSecOps, security is integrated into every stage of development, from design to deployment. This proactive approach ensures that security considerations are prioritized from the outset, reducing the risk of vulnerabilities.
DevSecOps practices: Shift Left + Automation + Culture
By shifting security “left” and emphasizing automation and continuous monitoring, DevSecOps enables organizations to detect and mitigate security threats in real-time. Collaboration between development, operations, and security teams further strengthens security measures, fostering a culture of shared responsibility. Embracing DevSecOps not only enhances the security posture of applications but also mitigates risks and preserves user trust in today’s increasingly threat-prone digital landscape.
DevSecOps in Practice: Securing the CI/CD pipelines of the 3-tier Web Application
A fully secured CI/CD pipeline integrates various security measures at every stage, ensuring the robustness of the software development process. Here’s how each component contributes to a secure pipeline:
- Pre-commit Hooks: Developers employ pre-commit hooks to enforce coding standards and security best practices before code is committed to the version control system. This ensures that potential vulnerabilities are addressed early in the development process.
- Secrets Management: Secrets management tools are utilized to securely store and manage sensitive information such as API keys, credentials, and passwords. Access to these secrets is tightly controlled, minimizing the risk of unauthorized access or exposure.
- Static Code Analysis (SCA) and Static Application Security Testing (SAST): SCA and SAST tools analyze the codebase for known security vulnerabilities and dependencies with known issues. They identify potential security flaws, such as SQL injection, XSS, or insecure dependencies, allowing developers to address them before deployment.
- Container Security: Before pushing the container image to the registry, container security measures are implemented to ensure the image’s integrity and security. This includes vulnerability scanning of the container image to detect and remediate any vulnerabilities or misconfigurations present within the image itself.
- Dynamic Application Security Testing (DAST): DAST tools simulate real-world attacks against the deployed application, identifying vulnerabilities that may arise in runtime. By testing the application from the outside, DAST tools can uncover security weaknesses that may not be apparent in static analysis.
- Vulnerability Management Tool: A vulnerability management tool is employed to track, prioritize, and remediate security vulnerabilities identified throughout the development process. This tool provides visibility into the security posture of the software and ensures that vulnerabilities are addressed promptly.
Next, we will delve into each security measure in depth, providing a comprehensive examination alongside a practical illustration.
Pre-Commit Hµooks
In Git, ‘pre-commit hooks’ play a pivotal role in our workflow. They help us detect secrets by running automated checks before each commit. This ensures that we can identify and prevent inadvertently including sensitive information, like authentication details or API keys, into our Git repository. It’s an important safeguard in our journey of writing clean and secure code.
For the next steps, we will use the tool ggshield.
Firstly, we install the tool locally within the project’s source code directory.
By default, Git hooks are shell script files (to activate a script, you need to remove .sample from the file) located within the hooks folder inside the hidden .git directory (which is not included when pushing to a remote repository). Therefore, after installing ggshield, we noticed that a script had been added to this folder.
Now, we need to add the API_KEY to the .env file in order to execute the ggshield script. To do this, we created an account with GitGuardian and generated an API_KEY.
Now, when committing, ggshield performs an analysis of the directory. If it detects a secret such as an API Key, a Token, etc., the commit will be blocked.
In this example, we didn’t add the .env file, which contains the API_Key, to the .gitignore file. We can see that the commit is blocked. (Files included in .gitignore will not be scanned as they will not be published in a remote directory).
Now, by adding .env to .gitignore, we notice that the commit goes through.
Static Application Security Testing (SAST)
SAST (Static Application Security Testing) is a method of statically analyzing the source code of an application to detect and prevent security vulnerabilities before execution.
We will use the SonarCloud tool.
First, we create a Token on SonarCloud.
We add it to the repository’s secrets to use it in the pipeline.
Let’s start with the backend:
Firstly, we need to add some properties from the SonarCloud account to the pom.xml file.
Specifically for Java projects, since there is no pre-built action to use, we need to modify the command used to build the project to include SAST tests.
Get Blogs4devs’s stories in your inbox
Join Medium for free to get updates from this writer.
We make the change at the build action level. Since accessing “secrets” is not possible from an action, we’ll input them as environment variables in the main pipeline.
Now, we execute the pipeline.
To view the test result, we access the provided link.
Now, for the frontend project:
Firstly, we need to create a sonar-project.properties file at the project directory level and add some properties.
For Angular projects, there is already an action available to run SAST tests with SonarCloud.
We execute the pipeline.
The project name hasn’t changed simply because we have already performed tests on the backend project.
Software Composition Analysis (SCA)
SCA (Software Composition Analysis) is a method of analysis that evaluates the third-party dependencies of an application to identify and address potential vulnerabilities related to the use of open-source software components.
We used the Snyk tool.
First, we created an account with Snyk and linked it to a GitHub account. Then, we imported the project and generated an API key.
Next, we add the API key (API_KEY) to the repository’s secrets.
Then, we add a job containing the action that will execute the SCA tests. Before analyzing dependencies, it’s necessary to build the application as indicated by the Snyk tool.
To run the pipeline, we stoppe the other jobs just to avoid waiting too long and to see only the result of this new job.
To view the detailed test result, we accessed the provided link.
Container Security
Container security involves conducting tests on Docker images. In our case, we will perform this test after building the image and before publishing it to Docker Hub. For this step, we will use Snyk.
We add to the pipeline, after the image build and before the push, the action that will perform tests on the built image.
Now, when we run the pipeline, we first perform SAST and SCA tests in parallel. Then, we build the application, build the image, perform container tests, and finally push to DockerHub.
We execute the pipeline now.
To see more details on the result of the image test, we access the link provided by Snyk at the end of the test.
Dynamic Application Security Testing (DAST)
DAST (Dynamic Application Security Testing) is a dynamic analysis method that evaluates application security by testing them during execution to identify potential vulnerabilities and security weaknesses. Unlike SAST, DAST simulates external attacks to assess the resilience of a running application.
For this part, we will use the OWASP ZAP tool.
To perform these tests, we first need to run the application. However, since we will use an action to conduct the tests and we cannot run the application with the “docker run” command, we run the application as a service. Thus, at the action level, we can access the application via localhost, since in this case, the application and the action will be executed in the same container.
We also need to add a step to verify that the application was executed successfully before starting the tests.
We stop the other jobs and test with the “latest” version just to quickly see if the DAST test succeeds.
We can do the same thing with the backend.
We execute the pipeline now.
The test report is added to the “Issues” section of GitHub.
That concludes this blog. See you in the next one! 👍
