You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+48-52Lines changed: 48 additions & 52 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ The OWASP DevSecOps Guideline explains how we can implement a secure pipeline an
3
3
This project helps any companies of each size that have a development pipeline or, in other words, have a DevOps pipeline.
4
4
We try to draw a perspective of a secure DevOps pipeline during this project and then improve it based on our customized requirements.
5
5
6
-
The Ideal goal is **"detect security issues (by design or application vulnerability) as fast as possible."**
6
+
The Ideal goal is **"detect security issues (by design or application vulnerability) as early as possible."**
7
7
8
8
## Initial steps
9
9
DevSecOps is all about putting security into DevOps. But to keep up with the pace of CI/CD, security has to be injected early into software writing and testing.
@@ -37,58 +37,54 @@ However, when using CI/CD tools to provide automation, keep in mind that the too
The OWASP DevSecOps Guideline explains how we can transition from a traditional approach to achieving security that starts with requirements and ends with security testing to an approach that brings together Development, Security, and Operations throughout the software lifecycle -- a "DevSecOps" approach.
3
+
4
+
This project's goal is to help companies of any size to add security to their DevOps pipeline and culture. There is no one **right** way to do DevSecOps, so it's important to stay focused.
5
+
6
+
DevSecOps strives to **"produce demonstrably secure code"** by:
7
+
* leveraging automation to create short feedback loops to developers
8
+
* breaking down the silos between development, security, and operations
9
+
* breaking down security work into small pieces to create flow
10
+
* making decisions based on threat intelligence from operations
11
+
* establishing a culture of security experimentation and learning
12
+
13
+
There are tools to support security processes across the software development lifecycle. Every company should have processes in place to ensure:
14
+
***Custom Code Security** - your custom code has the right defenses and is free from vulnerabilities, including applications, APIs, serverless, mobile, infrastructure as code, etc...
15
+
***Supply Chain Security** - your platform, framework, libraries, containers, and other components
16
+
***Runtime Protection** - you detect attacks on your software and prevent them from being exploited
17
+
18
+
If you do these three processes well, you will be in relatively good shape in terms of application security. In this document, we will explore a variety of automated solutions that can help you implement these three processes.
19
+
20
+
The goal is not to use all of the tools in your pipeline. The goal is to ensure secure code emerges from your pipeline. You need to pick and choose the tools that are effective with your organization's people, process, technology, and culture. You will very likely want to use each tool for what it is best at, rather than repeating all tests with all tools. Of course, every software development organization is different and you are free to select tools and the exact location where you want to implement the tools.
The Pre-commit phase is important because it can prevent security issues before they are submitted to a central (Git) repository.
4
+
5
+
Making sure that there are no secrets in the code, and that the code follows certain guidelines (According to the Linter rules) will result in a higher quality code.
6
+
7
+
In the following, we take a look into different types of pre-commit actions that are as follows:
8
+
1. Secrets Management
9
+
2. Linting Code
10
+
11
+
12
+
The following image can give you a better view of what the pre-commit means and why we must consider it.
Well, the best location is the **pre-commit** location, This ensure that before a secret actually enters your code base, it is intercepted, and the developer or to committer gets a message. Another location is the build server or the **build** process. The build server retrieves source code, which is already committed and then it can analyze the source code where it contains new secrets or when it contains known secrets that the secrets are actually validated or audited.
38
+
39
+
---
40
+
Here are some helpful tools to automatically scan repositories for sensitive information.
41
+
Scans can be implemented directly in our pipeline, and be repeatable and efficient.
42
+
43
+
## Tools:
44
+
-**Open-source**:
45
+
+[gittyleaks](https://github.com/kootenpv/gittyleaks) - Find sensitive information for a git repo
46
+
+[git-secrets](https://github.com/awslabs/git-secrets) - Prevents you from committing secrets and credentials into git repositories
47
+
+[Repo-supervisor](https://github.com/auth0/repo-supervisor) - Scan your code for security misconfiguration, search for passwords and secrets
48
+
+[truffleHog](https://github.com/dxa4481/truffleHog) - Searches through git repositories for high entropy strings and secrets, digging deep into commit history
49
+
+[Git Hound](https://github.com/ezekg/git-hound) - Git plugin that prevents sensitive data from being committed
50
+
+[Github Secret Scanning](https://docs.github.com/en/code-security/secret-scanning) - Github built in feature for secret detection
51
+
52
+
-**Proprietary software**:
53
+
+[GitGuardian](https://gitguardian.com) - Keep secrets out of your source code
+[TruffleSecurity](https://trufflesecurity.com) - Unhearth your secrets
56
+
+[GitHub Advanced Security](https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning) - GitHub scans repositories for known types of secrets, to prevent fraudulent use of secrets that were committed accidentally
57
+
+[BluBracket](https://blubracket.com) - Prevent secrets and credentials in code
58
+
+[Nightfall](https://nightfall.ai) - Find and protect secrets and keys across the cloud
Linting is the automated checking of your source code for programmatic and stylistic errors. This is done by using a lint tool (otherwise known as linter). A lint tool is a basic static code analyzer.
5
+
6
+
### What can Linting do?
7
+
- Linting can **detect errors** in a code and errors that can lead to a security vulnerabilities.
8
+
- Linters Can Also **detect formatting or styling issues** and makes the code more readable for more secure code.
9
+
- Linters can **suggest best practices**.
10
+
- Also they can **increases overall quality of the code**.
11
+
- Since everybody follows the same linting rules it **makes maintenance of code easier**.
12
+
13
+
14
+
### Basic Lint Tools
15
+
Lint tools are the most basic form of static analysis. Using lint tools can be helpful for identifying common errors, such as:
16
+
- Indexing beyond arrays.
17
+
- Dereferencing null pointers.
18
+
- (Potentially) dangerous data type combinations.
19
+
- Unreachable code.
20
+
- Non-portable constructs.
21
+
22
+
### Advanced Static Analysis Tools
23
+
Advanced static analysis tools typically deliver:
24
+
- Pattern-based simulation.
25
+
- Quality and complexity metrics.
26
+
- Best practice recommendations for developers.
27
+
- Support for multiple safety and security-focused coding standards.
28
+
- Out-of-the-box certification for use in the development of safety-critical applications.
29
+
30
+
### Issues with Linters
31
+
+ Not every language has "quality" standard linter tools available, each framwork usually has one or several linters.
32
+
+ Different versions or configurations can lead to different results.
33
+
+ Since some linters are very verbose and information overload can lead to focusing on "unimportant" issues.
You can perform it in the **pre-commit** phase, so locally before actually committing code to your local repository to your local clone. Another phase where you often see linting is during the **build** phase, So here the build server pulls the code from the Git repository and performs linting on it and reports back that results from linting phase.
0 commit comments