diff --git a/2023.md b/2023.md index 571864e..89522eb 100644 --- a/2023.md +++ b/2023.md @@ -51,7 +51,7 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich - [✔️] ⌨️ 9 > [SAST Implementation with SonarCloud](2023/day09.md) - [✔️] ⌨️ 10 > [Software Composition Analysis Overview](2023/day10.md) - [✔️] ⌨️ 11 > [SCA Implementation with OWASP Dependency Check](2023/day11.md) -- [] ⌨️ 12 > [](2023/day12.md) +- [✔️] ⌨️ 12 > [Secure Coding Practices](2023/day12.md) - [] ⌨️ 13 > [](2023/day13.md) ### Continuous Build, Integration, Testing diff --git a/2023/day12.md b/2023/day12.md index e69de29..30b24ca 100644 --- a/2023/day12.md +++ b/2023/day12.md @@ -0,0 +1,33 @@ +# Day 12: Secure Coding Review + +Secure code review is the process of examining and evaluating the security of a software application or system by reviewing the source code for potential vulnerabilities or weaknesses. This process is an essential part of ensuring that an application is secure and can withstand attacks from cyber criminals. + +There are several steps involved in a secure code review process: + +1. **Identify the scope of the review**: The first step is to identify the scope of the review, including the type of application being reviewed and the specific security concerns that need to be addressed. +2. **Set up a review team**: A review team should be composed of individuals with expertise in different areas, such as security, coding, and testing. The team should also include individuals who are familiar with the application being reviewed. +3. **Prepare the code for review**: Before the review can begin, the code needs to be prepared for review by organizing it in a way that makes it easier to understand and review. This may include breaking the code down into smaller chunks or adding comments to explain the purpose of specific sections. +4. **Conduct the review**: During the review, the team will examine the code for vulnerabilities and weaknesses. This may include checking for insecure coding practices, such as hardcoded passwords or unencrypted data, or looking for vulnerabilities in the application’s architecture. +5. **Document findings**: As the team identifies potential vulnerabilities or weaknesses, they should document their findings in a report. The report should include details about the vulnerability, the potential impact, and recommendations for how to fix the issue. +6. **Remediate vulnerabilities**: Once the review is complete, the team should work with the development team to fix any vulnerabilities or weaknesses that were identified. This may involve updating the code, implementing additional security controls, or both. + +There are several tools and techniques that can be used to facilitate a secure code review. These may include: + +1. **Static analysis tools**: These tools analyze the code without executing it, making them useful for identifying vulnerabilities such as buffer overflows, SQL injection, and cross-site scripting. +2. **Dynamic analysis tools**: These tools analyze the code while it is being executed, allowing the review team to identify vulnerabilities that may not be detectable through static analysis alone. +3. **Code review guidelines**: Many organizations have developed guidelines for conducting code reviews, which outline the types of vulnerabilities that should be looked for and the best practices for remediation. +4. **Peer review**: Peer review is a process in which other developers review the code, providing a second set of eyes to identify potential vulnerabilities. + +Secure code review is an ongoing process that should be conducted at various stages throughout the development lifecycle. This includes reviewing code before it is deployed to production, as well as conducting periodic reviews to ensure that the application remains secure over time. + +Overall, secure code review is a critical component of ensuring that an application is secure. By identifying and addressing vulnerabilities early in the development process, organizations can reduce the risk of attacks and protect their systems and data from potential threats. + +I highly recommend watching this video to understand how source code analysis can lead to finding vulnerabilities in large enterprise codebases. + +[![Final video of fixing issues in your code in VS Code](https://img.youtube.com/vi/fb-t3WWHsMQ/maxresdefault.jpg)](https://www.youtube.com/watch?v=fb-t3WWHsMQ) +### Resources + +- [How to Analyze Code for Vulnerabilities](https://www.youtube.com/watch?v=A8CNysN-lOM&t) +- [What Is A Secure Code Review And Its Process?](https://valuementor.com/blogs/source-code-review/what-is-a-secure-code-review-and-its-process/) + +In the next part [Day 13](day13.md), we will discuss Additional Secure Coding Practices with some more hands-on. \ No newline at end of file diff --git a/2023/day13.md b/2023/day13.md index e69de29..949222a 100644 --- a/2023/day13.md +++ b/2023/day13.md @@ -0,0 +1,87 @@ +# Day 13: Additional Secure Coding Practices + +## Git Secret Scan + +Scanning repositories for secrets refers to the process of searching through a code repository, such as on GitHub or GitLab, for sensitive information that may have been inadvertently committed and pushed to the repository. This can include sensitive data such as passwords, API keys, and private encryption keys. + +The process is usually done using automated tools that scan the code for specific patterns or keywords that indicate the presence of sensitive information. The goal of this process is to identify and remove any secrets that may have been exposed in the repository, in order to protect against potential breaches or unauthorized access. + +### Git Secret Scan with Gitleaks + +Gitleaks is a tool that can be added to your GitHub repository as a GitHub Action, which scans your codebase for sensitive information such as credentials, tokens, and other secrets. The action runs the gitleaks tool on your codebase, which checks for any sensitive information that may have been accidentally committed to your repository. + +To set up Gitleaks GitHub Action, you need to create a new workflow file in your repository's `.github/workflows/git-secret-scan.yml` directory. The workflow file should contain the following: + +```yaml +name: gitleaks +on: + pull_request: + push: +jobs: + scan: + name: gitleaks + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + with: + fetch-depth: 0 + - uses: gitleaks/gitleaks-action@v2 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} +``` + + +This workflow does the following: + +1. Defines a workflow called `Dependency-Check` that runs on every push to the `main` branch. +2. Specifies that the workflow should run on the `ubuntu-latest` runner. +3. Runs gitleaks scan for the entire repository +4. This action will fail if it detects any secret. + +In my demo, I have added AWS Keys in .env file and because of that the pipeline faild. + +![](images/day13-1.png) + +Other Git Scanner tools + +- [**AWS git-secrets**](https://github.com/awslabs/git-secrets) +- **[GitGuardian ggshield](https://github.com/GitGuardian/ggshield)** +- **[TruffleHog](https://github.com/trufflesecurity/trufflehog)** + +### Resources +- [Gitleaks GitHub](https://github.com/zricethezav/gitleaks) +- [Gitleaks GitHub Action](https://github.com/gitleaks/gitleaks-action) +## Create better Dockerfile with Hadolint + +Hadolint is a linter for Dockerfiles that checks for common mistakes and provides suggestions for improvement. It can be used directly from the command line, integrated into a CI/CD pipeline, or integrated into code editors and IDEs for real-time linting. + +To set up linting with hadolint in Github Actions, you can use the following steps: + +1. Create a new workflow file in your repository, for example `.github/workflows/dockerfile-lint.yml` +2. In this file, add the following code to set up the Github Actions workflow: + +```yaml +name: Lint Dockerfile +on: + push: + branches: + - main +jobs: + lint: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + - uses: hadolint/hadolint-action@v2.1.0 + with: + dockerfile: Dockerfile +``` + +1. This workflow will run on every push to the "main" branch, and will run the hadolint command on the "Dockerfile" file. +2. Commit the new workflow file and push it to your repository. +3. Next time you push changes to the "main" branch, Github Actions will run the linting job and provide feedback if any issues are found with your Dockerfile. + +### Resources + +- [Hadolint GitHub](https://github.com/hadolint/hadolint) +- [Hadolint Online](https://hadolint.github.io/hadolint/) +- [Top 20 Dockerfile best practices](https://sysdig.com/blog/dockerfile-best-practices/) \ No newline at end of file diff --git a/2023/images/day13-1.png b/2023/images/day13-1.png new file mode 100644 index 0000000..2faf17d Binary files /dev/null and b/2023/images/day13-1.png differ diff --git a/Contributors.md b/Contributors.md index 25226ba..2d8cdf0 100644 --- a/Contributors.md +++ b/Contributors.md @@ -517,4 +517,4 @@ Contributors - + \ No newline at end of file