CODE Phase: Enhancing Security with IDE Security Plugin,Secret Detection, SAST, and SCA

Introduction

During the code phase of our software development lifecycle, we're employing a layered security approach. This involves:

1. Pre-commit Hooks for Secret Detection on local

2. Secret Detection Tool on Gitlab

3. Static Application Security Testing (SAST)

4. Software Composition Analysis (SCA)

5. Branch Protection and Code Reviews

Pre-commit Hooks for Secret Detection

Overview:

Ensure that secrets aren't accidentally committed to the repository.

Implementation:

• Utilize pre-commit hooks to invoke the secret detection tool before each commit.

• If the tool identifies potential secrets, block the commit and notify the developer.

Secret Detection Tool

Overview:

Prevent accidental commitment of sensitive information like passwords, API keys, and other secrets.

Implementation:

• Install the desired secret detection tool.

• Configure the tool to scan directories containing code.

• Run the tool before every commit to ensure no secrets are being exposed.

Static Application Security Testing (SAST)

Overview:

Analyze the application's source code, bytecode, or binary code without executing it, identifying potential vulnerabilities.

Implementation:

• Choose a SAST solution compatible with the application's programming language and framework.

• Regularly analyze the codebase, prioritizing findings based on severity.

Software Composition Analysis (SCA)

Overview:

Identify and address vulnerabilities present in open-source components and libraries.

Implementation:

• Implement a relevant SCA tool.

• Regularly check for outdated libraries or those with known vulnerabilities. Upgrade or replace as necessary.

Branch Protection and Code Reviews

Overview:

Protect critical branches from direct pushes and enforce a code review process to maintain code quality and security.

Implementation:

1. Protected Branch:

   • Set up branch protection rules. Ensure only reviewed and approved changes can be merged.

   • Restrict direct pushes to critical branches.

2. Code Reviews:

   • Enforce mandatory code reviews before merging changes.

   • Train the team to look for security and quality issues during reviews.

Create a new project in GitLab

Step 1 – Login to GitLab using your username and password.

Step 2 – In your dashboard, click the blue New project button. This opens the New project page.

Step 3 – The New project page provides 4 options to select:

1. Create a blank project.

2. Create a project using one of the available project templates.

3. Import a project from a different repository, if enabled on your GitLab instance.

4. Run CI/CD pipelines for external repositories.

As I have mentioned earlier, I want to create a new empty project, so I will select open 1 (Create a blank project).

Step 4 – A new page will open. Provide the following information on that page:

• Project Name – Mention the name of your project in the Project name field – Ghost CMS. You can’t use special characters, but you can use spaces, hyphens, underscores, or even emojis.

• Project slug – When a name is added, the Project slug auto-populates. The path to your project is in the Project slug field. This is the URL path for your project that the GitLab instance uses. If the Project name is blank, it auto populates when you fill in the Project slug. If you want a different slug, input the project name first, then change the slug after.

• Project description (optional) – This field enables us to enter a description for your project’s dashboard, which helps others understand what your project is about. Though it’s not required, it’s a good idea to fill this in.

• Visibility Level – Selected the Private for our project.

• Selecting the Initialize repository with a README option creates a README file so that the Git repository is initialized, has a default branch, and can be cloned.

Select the Create Project button.

We have just created a new and empty project in GitLab. Now we can clone this project and start working on it.

I cloned this repo to my local

Then downloaded ghost GitHub repo from - https://github.com/TryGhost/Ghost and copied them to my local ghost repo

After copying the repo, i opened it from Visual Studio Code editor

Then scanned with Snyk plugin for vulnerabilities and found several vulnerabilities.

Despite it is testing case, here I have written what to do in my situation and in real world scenarios

Pushing to remote development repo

After pushing code to the remote repository, it is imperative to conduct a secret detection scan. Additionally, a vulnerability assessment should be carried out using a Static Application Security Testing (SAST) tool. To ensure consistent and automated execution, integration with the CI/CD pipeline is essential. For that, I added some configs to gitlab-ci.yaml

gitlab-ci.yaml

stages:
  - sast
  - secret_detection


snyk_sast_scan:
  stage: sast
  image: 
    name: snyk/snyk-cli:1.1205.0-docker
    entrypoint: [""]
  script:
    - npm install -g npm@latest
    - npm install -g synk
    - echo $SNYK_TOKEN
    - snyk auth $SNYK_TOKEN -d
    - snyk code test --org=785253e7-a8e7-412e-a88b-b1f89e0e2d08
    - snyk monitor --all-projects --org=785253e7-a8e7-412e-a88b-b1f89e0e2d08
  allow_failure: true


.secret-analyzer:
  stage: secret_detection
  image: "$SECURE_ANALYZERS_PREFIX/secrets:$SECRETS_ANALYZER_VERSION$SECRET_DETECTION_IMAGE_SUFFIX"
  services: []
  allow_failure: true
  variables:
    GIT_DEPTH: "50"
  artifacts:
    reports:
      secret_detection: gl-secret-detection-report.json

secret_detection:
  extends: .secret-analyzer
  rules:
    - if: $SECRET_DETECTION_DISABLED == 'true' || $SECRET_DETECTION_DISABLED == '1'
      when: never
    - if: $CI_COMMIT_BRANCH
  script:
    - /analyzer run