Introduction

Hi! And welcome to the DevSecOops handbook. An educational approach, complementary to our @theredguild/devsecops-toolkit where we provide practical aid on how to use some of the tools depicted there.

To start, you should have at least built the workshop-minimal image of that container. There are several ways you could do this, but I'm going to show you only two, one remote and one local.

Setup: Option 1 - GitPod (preferred)

Literally just click here and that's almost it. I'd choose Terminal, Large, Ctrl + Enter and you're done. You just need to run make exec.

Here we can build the entire repository from develop since connectivity issues won't be a problem.

Setup: Option 2 - Local container

Clone the repo inside your computer, checkout workshop-minimal, and exec, easy peasy. Note that if you're in one of our workshops, inside a venue, things might go a tad slow.

git clone https://github.com/theredguild/devsecops-toolkit
git checkout workshop-minimal
make exec

Start

Once you've built the container, you should be able to see something similar to this.

❯ make exec
fatal: No names found, cannot describe anything.
Running interactive shell inside the devsecops-toolkit container...
                    __        __   _                               
                    \ \      / /__| | ___ ___  _ __ ___   ___      
                     \ \ /\ / / _ \ |/ __/ _ \| '_ ` _ \ / _ \     
                      \ V  V /  __/ | (_| (_) | | | | | |  __/     
                    __ \_/\_/ \___|_|\___\___/|_| |_| |_|\___|     
                    \ \      / /_ _ _ __   __| | ___ _ __ ___ _ __ 
                     \ \ /\ / / _` | '_ \ / _` |/ _ \ '__/ _ \ '__|
                      \ V  V / (_| | | | | (_| |  __/ | |  __/ |   
                       \_/\_/ \__,_|_| |_|\__,_|\___|_|  \___|_|   

                         Welcome to the devsecops toolkit
                            Built by The Red Guild 🪷

    This container was created as a resource for a workshop, 
    which intends to spread awareness, help people protect themselves 
    and the repos they interact with. Say hi @theredguild!, don't be a stranger.

wanderer@trg ~ $ 

And now you're ready to follow the rest of the chapters! We hope you like it.

Disclaimer

As we mentioned above, this is an educational repository, which currently includes the content of this practical handbook. In the future, it may also feature more specific selected examples to test each tool.

Our focus has recently shifted more towards operational security, so we haven't used these tools daily or to their full extent. However, they are a selection and curation of our own after thorough research, testing, and consulting with others :).

If you're looking for more tools, you can check out develop, but be aware that in its current state, it weighs nearly 9GB. The workshop-minimal version should not exceed 3.5GB.

Once you've grasped how and where to use them, you might want to explore further to extract all the juice, or even use them separately, most of them include their own separate container.

GitHub Analysis

As you already know, there has been a surge in fake profiles and impersonation in github profiles, contributors, or even backdoored repositories. So here we bring you two tools to help you get some of the basic information you need in order to be able to identify these cases.

GitXRay

One tool that works out of the box is gitxray, by a fellow hacker from the @ekoparty, Lucas. The only thing I'd suggest doing if you want to actually do a profound analysis, is that by default it uses GH's public access token, so you'll need to add an environment variable when you call it. Othwerwise, to do a shallow an quick analysis you're fine.

In case you want to do it, I'll guest creating a Fine-grained Personal Access Token that expires soon enough, with a representative name and Read Only access to Public Repositories.

GH_ACCESS_TOKEN="github_pat_11AABCCDDEE13802849209HD09283CDFFF" gitxray -r theredguild/devsecoops -l -v

You should see: GitHub Token Loaded from GH_ACCESS_TOKEN env variable, this means you're ready to go.

The first time I wanted to play with a tool like this one, was when I spent hours trying to understand what had happened with the xz backdoor, and how much involvement the infiltrator JiaT75 had in it. The repo is: https://github.com/tukaani-project/xz.

Let's do a basic analysis.

wanderer@trg ~ $ gitxray -r tukaani-project/xz -l -v
...
Now verifying repository: tukaani-project/xz
Identified 54 contributors..                                                                      
LISTING CONTRIBUTORS (INCLUDING THOSE WITHOUT A GITHUB USER ACCOUNT) AND EXITING..
Larhzu, JiaT75, thesamesam, adrien-n, jrn, hansjans162, kiyolee, mvatsyk-lsg, afb, [email protected], [email protected], junghans, gabibguti, jmarrec, [email protected], kianmeng, vapier, skosukhin, stoeckmann, jcallen, kilobyte, bluhm, svpv, radarhere, Coeur, mathstuf, bebuch, [email protected], ChanTsune, parheliamm, ivq, DimitriPapadopoulos, emaste, firasuke, hjl-tools, addaleax, iv-m, Jamaika1, jbastian, [email protected], meyering, [email protected], nickajacks1, praiskup, [email protected], RainRat, ryandesign, sebastianas, vnwildman, scop, xry111, yarikoptic, biergaizi, huangqinjin

We can see JiaT75 appearing second. Let's add that username as a parameter to the previous command I'm going to skip to some of the most interesting parts I want to show you.

wanderer@trg ~ $ gitxray -r tukaani-project/xz -c JiaT75
....
Now verifying repository: tukaani-project/xz
YOU HAVE SCOPED THIS GITXRAY TO CONTRIBUTORS: ['JiaT75'] - OTHER USERS WON'T BE ANALYZED.
[comments]:   The Issues comment with the most NEGATIVE reactions (66) is available at: https://github.com/tukaani-project/xz/issues/92#issuecomment-2027786734
[branches]:   12 Unprotected Branches: ['build_werror', 'build_werror2', 'mask_cntrl_chars', 'master', 'memavail', 'single_stream_keeps', 'v5.0', 'v5.2', 'v5.4', 'v5.6', 'version_txt', 
[releases]:   User JiaT75 created historically 10 releases [71.43%] and uploaded a total of 60 assets [66.67%] Turn on Verbose mode for more information.
[contributors]: Top repository contributors with rejected PRs: [stoeckmann 2 rejected out of 2] | [thesamesam 2 rejected out of 2] | [skosukhin 2 rejected out of 2]
[contributors]: Top non-contributor GitHub users with rejected PRs: [brad0 2 rejected out of 2] | [ChenPi12 1 rejected out of 1] | [wzhengsen 1 rejected out of 1]
Some profiling:
[workflows]:  Workflow [CI] created [2022-12-22T13:37:40.000-03:00], updated [2022-12-22T13:37:40.000-03:00]: [https://github.com/tukaani-project/xz/blob/master/.github/workflows/ci.yml]
[workflows]:  Workflow [CI] has [121] missing or deleted runs. This could have been an attacker erasing their tracks, or legitimate cleanup. Set verbose mode for more data. 
[workflows]:  Workflow [CI] was run by [2] NON-contributors [2] times and by [7] contributors [7] times. Set verbose mode for more data. [https://github.com/tukaani-project/xz/actions/workflows/ci.yml]

And now specifically about JiaT75

Found results for account JiaT75.
[urls]:       Contributor URL: https://github.com/JiaT75
[urls]:       Owned repositories: https://github.com/JiaT75?tab=repositories
[personal]:   [Name: Jia Tan] obtained from the user's profile.
[emails]:     [[email protected]] obtained from the user's profile.
[emails]:     [[email protected]] obtained by parsing commits.
[profiling]:  Contributor account created: 2021-01-26T18:11:07Z, is 3.73 years old.
[profiling]:  The account was last updated at 2024-03-29T20:19:23Z, 202 days ago.
[profiling]:  Contributor has 10 total public repos.
[profiling]:  Contributor has 646 followers.
[profiling]:  The user submitted 29 Pull Requests out of which 5 were rejected.
[profiling]:  The user submitted 29 Pull Requests out of which 24 were merged.
[commits]:    Made (to this repo) 452 commits, first one at 2022-01-28T12:47:55Z and last one at 2024-03-25T17:50:02Z.
[commits]:    Commit Hours for [452] commits:
            [12pm UTC: 116 (25.66%)]
            [3pm UTC: 73 (16.15%)]
            [1pm UTC: 70 (15.49%)]
            [2pm UTC: 57 (12.61%)]
            [4pm UTC: 52 (11.50%)]
            [5pm UTC: 18 (3.98%)]
            [11am UTC: 16 (3.54%)]
            [8am UTC: 13 (2.88%)]
            [10am UTC: 7 (1.55%)]
            [2am UTC: 6 (1.33%)]
            [3am UTC: 5 (1.11%)]
            [1am UTC: 4 (0.88%)]
            [4am UTC: 4 (0.88%)]
            [7am UTC: 3 (0.66%)]
            [9am UTC: 3 (0.66%)]
            [5am UTC: 1 (0.22%)]
            [7pm UTC: 1 (0.22%)]
            [6am UTC: 1 (0.22%)]
            [12am UTC: 1 (0.22%)]
            [6pm UTC: 1 (0.22%)]

As you can see, with only some basic parameters we have a lot of data from which we can infer more information to our research. Like for example, where that person might live if their commits were pushed during the workday, or maybe after work.

Fake Analyzer

This tool allows you to select a username, without the need for a repository or an organization. It just looks through almost anything it can find and creates a JSON report for you to inspect.

Let's start with an example of their repo, running the tool against eduales99.

gh-analyze --token github_pat_11AABCCDDEE13802849209HD09283CDFFF eduales99

It begins displaying the requests it is doing, like followers/following, info about their repos, and more, you can check the rest of the log in script.log. The report will be found at out/eduales99/report.json. You can specify where to ouput the files if you wanted to.

Let's see some of the fields it outputs.

Emails associated with that account from interactions:

    "unique_emails": [
        {
            "email": "[email protected]",
            "name": "eduales99"
        },
        {
            "email": "[email protected]",
            "name": "Never Give Up"
        },
        {
            "email": "[email protected]",
            "name": "GitHub"
        },
        {
            "email": "49699333+dependabot[bot]@users.noreply.github.com",
            "name": "dependabot[bot]"
        },
        {
            "email": "[email protected]",
            "name": "NGUD-0119: ACE"
        },
        {
            "email": "[email protected]",
            "name": "NGUD-0119"
        },
        {
            "email": "[email protected]",
            "name": "Eduardo Morales Cortes"
        },
        {
            "email": "[email protected]",
            "name": "sebastian4098"
        }
    ],

Repository list, as you can see a lot of web3 projects in there..

"repo_list": [
    "auction-dApp-Ethereum",
    "bancor-protocol-contracts",
    "boilerplate-ethereum",
    "borrowAndrepayNFT",
    "cryptowallet-app",
    "d3-chart",
    "Developer-Dashboard",
    "dfs-token-contracts",
    "eduales99",
    "hardhart-smart-contract",
    "Javascript-Drawio",
    "lottery-contract",
    "TensorFlow-Models",
    "Viking-P2E-Game"
],

Even better yet, it shows you direct contributions to their repos:

"contributors": [
    {
        "repo": "auction-dApp-Ethereum",
        "contributors": [
            "eduales99"
        ]
    },
    {
        "repo": "lottery-contract",
        "contributors": [
            "sebastian4098",
            "eduales99"
        ]
    },

Contributions to other repositories.

"commits_to_other_repos": [
    {
        "repo": "sebastian4098/portfolio-GASP",
        "commits": [
            "2cf64d2ccb957eb37e6ee86d886f5ba19f268196",
            "a9e0971b14138fbe7baa467256072fd56afbefca"
        ]
    },
    {
        "repo": "sebastian4098/express-server",
        "commits": [
            "97c305583102afb9d904e9dd7b8f941dd926d3ca"
        ]
    }
],

From this, we can conclude there might be a relationship between sebastian4098 and eduales99.

Another interesting feature, is the "potential copy" section where it checks if the account was created after commit messages (no fork).

"potential_copy": [
    {
        "repo": "auction-dApp-Ethereum",
        "reason": "account creation date later than the first commit to the repository",
        "commit_date": "2017-07-01T00:13:16-05:00"
    },
    {
        "repo": "bancor-protocol-contracts",
        "reason": "account creation date later than the first commit to the repository",
        "commit_date": "2020-08-07T13:57:17+03:00"
    },
    {
        "repo": "boilerplate-ethereum",
        "reason": "account creation date later than the first commit to the repository",
        "commit_date": "2021-10-31T12:02:11+02:00"
    },
    {
        "repo": "borrowAndrepayNFT",
        "reason": "account creation date later than the first commit to the repository",
        "commit_date": "2022-09-17T23:49:03+09:00"
    },
    ...
]

There's much more we can do, and in case something gets deleted or tampered with, we have at least some of that data as a back-up.

Another cool feature it has, is that you can also monitor an account with gh-monitor.

wanderer@trg eduales99 $ gh-monitor -u mattaereal # removing token because of space
Starting to monitor activity for users: mattaereal
Press Ctrl+C to stop monitoring.
User: mattaereal, mattaereal starred the repository aquasecurity/cloudsploit, Date: 2024-10-17T19:56:14Z
User: mattaereal, mattaereal created a branch in theredguild/DevSecOps-toolkit, Date: 2024-10-17T19:48:27Z
User: mattaereal, mattaereal opened an issue in security-alliance/frameworks, Date: 2024-10-17T19:27:32Z
User: mattaereal, mattaereal updated the wiki in theredguild/DevSecOps-toolkit, Date: 2024-10-17T17:46:13Z
....
User: mattaereal is now following theredguild
User: mattaereal changed their name from 'None' to 'Matías Aereal Aeón'
User: mattaereal changed their company from 'None' to 'The Red Guild @theredguild '
User: mattaereal changed their blog from 'None' to 'blog.theredguild.org'
User: mattaereal changed their bio from 'None' to 'Hacker. Security generalist.
Doing quests @theredguild'
User: mattaereal changed their twitter_username from 'None' to 'mattaereal'
User: mattaereal profile was updated at 2024-08-01T14:05:00Z

If you're suspicious and want to track the behavior of a specific account, you can check it out. Some cybercriminals change usernames, delete repos, trying to start anew.

Permissions

Sometimes using many repositories and participating in several organizations can be a bit tedious wheen trying to assess permissions. There are some tools that can check them out for you and elaborate a report to let you know where you are weak or someone could leverage permissions.

A tool that does this is Legitify. We're not doing a tutorial about this tool for the workshop because we'd like to focus on more things (and it's not that hard to use).

Also, we don't want you to be in a room fool of hackers trying to create a new access token with this level of permissions on the fly, we might even see you don't use 2FA to change security settings and feel our wrath.

Other tools you could use:

trufflehog --no-update analyze # and select git/github, pasting your PAT

CI/CD

CI/CD pipelines automate software development but can be exploited if not secured. Attackers may inject malicious code, steal secrets, or escalate privileges, threatening the software supply chain. Securing these pipelines involves enforcing access controls, scanning for vulnerabilities, managing secrets, and integrating security checks to detect issues early and prevent attacks.

For this scenario we're going to use the repository cicd-goat from @cider-security-research.

git clone https://github.com/cider-security-research/cicd-goat

Since there are many ways on how you can inspect a vulnerable CI/CD, instead of deploying or running each challenge, and because it is not our intention to exploit them, we are going just to scan them to understand how some of these tools work.

Checkov

In this case we're going to use checkov, since it has the possibility to scan many frameworks:

all, ansible, argo_workflows, arm, azure_pipelines, bicep, bitbucket_pipelines, cdk,
circleci_pipelines, cloudformation, dockerfile, github_configuration, github_actions, gitlab_configuration,
gitlab_ci, bitbucket_configuration, helm, json, yaml, kubernetes, kustomize, openapi, sca_package, sca_image,
secrets, serverless, terraform, terraform_json, terraform_plan, sast, sast_python, sast_java, sast_javascript,
sast_typescript, sast_golang, 3d_policy

We're going to run it without further configuration just select a folder:

wanderer@trg ~ $ checkov -d cicd-goat/
[ arm framework ]: 100%|████████████████████|[44/44], Current File Scanned=../../../gite
[ dockerfile framework ]: 100%|████████████████████|[12/12], Current File Scanned=../../
[ kubernetes framework ]: 100%|████████████████████|[50/50], Current File Scanned=jenkin
[ terraform framework ]: 100%|████████████████████|[6/6], Current File Scanned=cicd-goat
[ secrets framework ]: 100%|████████████████████|[10/10], Current File Scanned=cicd-goat
[ gitlab_ci framework ]: 100%|████████████████████|[2/2], Current File Scanned=gitlab/repositories/awesome-app/.gitlab-ci.yml
[ circleci_pipelines framework ]: 100%|████████████████████|[1/1], Current File Scanned=.circleci/config.yml
[ github_actions framework ]: 100%|████████████████████|[41/41], Current File Scanned=.github/workflows/release.yaml
... continues

You can see the progress bar for each framework being scanned, and then you're going to see how many passed the tests or failed them. In this scenario there's an overload of information given we just fed it a LOT of vulnerable cases.

To avoid this, something you could do is select the quiet and compact view of the output.

checkov -d cicd-goat --quiet --compact
(trimming some warnings)

terraform scan results:
Passed checks: 32, Failed checks: 19, Skipped checks: 0

Check: CKV_GLB_1: "Ensure at least two approving reviews are required to merge a GitLab MR"
	FAILED for resource: gitlab_project.pygryphon_project
	File: /gitlab/gitlab.tf:73-79
	Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/build-integrity-policies/gitlab-policies/merge-requests-do-not-require-two-or-more-approvals-to-merge
Check: CKV_GLB_4: "Ensure GitLab commits are signed"
...

dockerfile scan results:
Passed checks: 652, Failed checks: 26, Skipped checks: 0

Check: CKV_DOCKER_1: "Ensure port 22 is not exposed"
	FAILED for resource: /prod/Dockerfile.EXPOSE
	File: /prod/Dockerfile:33-33
	Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/docker-policy-index/ensure-port-22-is-not-exposed
...
continues

If you disable compact, you will be able to see the vulnerable lines that made the test fail.

And there's much more that you can do, this tools scans for Docker images/files, secrets, and even allows you to plug-in OpenAI to improve the explanations.

Here's an example:

wanderer@trg ~ $ checkov -d cicd-goat/gitlab-runner/ --quiet --openai-api-key sk-3QqBtfJ...TUV-OWbB
WARNING: About to request 2 enhanced guidelines and it may take up to 15s.

dockerfile scan results:
Passed checks: 31, Failed checks: 2, Skipped checks: 0

Check: CKV_DOCKER_2: "Ensure that HEALTHCHECK instructions have been added to container images"
	FAILED for resource: /Dockerfile.
	Details: The following text is AI generated and should be treated as a suggestion.
	
	         The issue with the provided Dockerfile is that it does not include a HEALTHCHECK instruction.
	         According to the checkov policy 'Ensure that HEALTHCHECK instructions have been added to container images', it is recommended to include a HEALTHCHECK instruction in Dockerfiles to monitor the status of a container.
	
	         To fix this issue, you can add a HEALTHCHECK instruction to the Dockerfile.
	         Here is an example of how you can add a simple HEALTHCHECK instruction to the Dockerfile:
	
	         FROM docker:20.10.21-dind
	         ARG VERSION
	         ARG COMMIT_SHA
	
	         LABEL org.opencontainers.image.vendor="Cider Security" \
	             org.opencontainers.image.title="CI/CD Goat - GitLab Runner" \
	             org.opencontainers.image.description="Deliberately vulnerable CI/CD environment." \
	             org.opencontainers.image.url="https://hub.docker.com/r/cidersecurity/goat-gitlab-runner" \
	             org.opencontainers.image.source="https://github.com/cider-security-research/cicd-goat" \
	             org.opencontainers.image.licenses="Apache-2.0" \
	             org.opencontainers.image.version=$VERSION \
	             org.opencontainers.image.revision=$COMMIT_SHA
	
	         RUN apk add --no-cache gitlab-runner curl bash
	         COPY . /setup/
	         ENTRYPOINT ["/setup/run.sh"]
	
	         HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 CMD curl -f http://localhost/ || exit 1
	
	         In this example, a simple HTTP health check is added using the `curl` command to check if the container is healthy.
	         You can customize the HEALTHCHECK instruction based on your specific requirements and the service running inside the container.
	File: /Dockerfile:1-16
	Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/docker-policy-index/ensure-that-healthcheck-instructions-have-been-added-to-container-images

		1  | FROM docker:20.10.21-dind
		2  | ARG VERSION
		3  | ARG COMMIT_SHA
		4  |
		5  | LABEL org.opencontainers.image.vendor="Cider Security" \
		6  |     org.opencontainers.image.title="CI/CD Goat - GitLab Runner" \
		7  |     org.opencontainers.image.description="Deliberately vulnerable CI/CD environment." \
		8  |     org.opencontainers.image.url="https://hub.docker.com/r/cidersecurity/goat-gitlab-runner" \
		9  |     org.opencontainers.image.source="https://github.com/cider-security-research/cicd-goat" \
		10 |     org.opencontainers.image.licenses="Apache-2.0" \
		11 |     org.opencontainers.image.version=$VERSION \
		12 |     org.opencontainers.image.revision=$COMMIT_SHA
		13 |
		14 | RUN apk add --no-cache gitlab-runner curl bash
		15 | COPY . /setup/
		16 | ENTRYPOINT ["/setup/run.sh"]

We will leave secrets and container image scanning example to other tools.

GitHub Actions

There are many many ways you can check the security of your github actions, I'm going to leave you with some basic tools and possibly a few github actions that will hopefully get detected by them.

We are going to use GitHub Actions Goat, a deliberately vulnerable GH actions CI/CD environment, so we don't accidentally find vulnerabilities in live projects by accident :sweat:.

We're going to clone the repository:

git clone https://github.com/step-security/github-actions-goat

GitHub: Tindersec's Workflow Auditor

And start by using a tool called gh-workflow-auditor by @TinderSec. This tool not only scans for actions, but the entire workflow. It looks for malicious or ill-intended inputs, from commits' title messages, to author's name or email fields.

Exporting PAT on the same line, run it like this:

wanderer@trg ~ $ PAT=github_pat_11ahshdasadasdkjasdhksajdsaj gh-workflow-auditor --type repo step-security-github-actions-goat

Since we aren't using a real setup (a repository with commits, issues), and in this case it is only looking through a bunch of yml files, the full potential of the tool is not being exploited.

GitHub: Octoscan Static Vuln Scanner

There's also another interesting tool we've found worth mentioning, and it is Octoscan.

It has two commands, dl (download) and scan. Let's start with the first one:

wanderer@trg ~ $ octoscan dl --org theredguild --repo devsecops-toolkit --token github_pat_11AABCCDDEE13802849209HD09283CDFFF

If you check your current working directory, you'll see an output folder, where it as inclided for the target repo all the branches' workflows to be analyzed locally.

wanderer@trg octoscan-output/DevSecOps-toolkit $ ls
ci-moar-space			os-motd
develop				os-pipx-path-and-shell-prompt
docker-compose			readme-docs-1
dockerfile-gosu			readme-todo-list
dockerfile-merge-runs		tool-2ms-and-zsh
docs-create-howto		tool-dockle
docs-readme-motd		tool-hadolint-kics
gha-tests			tool-semgrep-and-reorder
main				tools-clair
misc-dockerfile-make-docs	tools-fixes-1
misc-dockerfile-readme-1	tools-fixes-2
misc-hostname-motd		tools-scoutsuite-checkov-pmapper
multi-dockerfile-readme		tools-versions
multi-tools-pipx-git-asdf-npm	workshop-minimal
multi-tools-snyk-grype-and-more

In our case, I know the workflow for each branch is almost the same, except for a few. In order to reduce redundancy, you can delete duplicated workflows by using the fdupes command first.

fdupes -n -r -N -d path/to/repo

Now, you can then run a scan directly to the output. Note that if you already have the repository locally, there's no need to download it like we did.

wanderer@trg ~ $ octoscan scan octoscan-output/theredguild/DevSecOps-toolkit
octoscan-output/theredguild/DevSecOps-toolkit/ci-moar-space/.github/workflows/test-tools.yml:47:27: Expression injection, "steps.**.outputs.**" is potentially untrusted. [expression-injection]
   |
47 |           build-args: ${{ steps.dotenv.outputs.vars }}
   |                           ^~~~~~~~~~~~~~~~~~~~~~~~~

You can check all the rules being used by running octoscan scan --list-rules, so you may disable the ones you don't need with --disable rules. Their documentation suggests to use this command as a first one when you don't know where to start:

octoscan scan path/to/repos/ --disable-rules shellcheck,local-action --filter-triggers external

The README from Octoscan provides a great explanation with real examples from each of the rules it uses.

There is also a great guide by the Security Lab at GitHub in order to prevent what they call pwn requests.

If you want to add an action that proportionates a wide range of security measures, you can start by installing HardenRunner. It provides runtime security for GitHub-hosted and self-hosted runners:

- name: Harden-Runner
  uses: step-security/[email protected]

Secrets

Secrets, passwords, credentials... you name it. They are everywhere because they are needed. Tokens, API keys, private keys leaks and more are the sole reason of why some projects get rekt. They keep getting pushed to repositories accidentally, or sometimes a colleage pasted it in a Discord channel thinking it might not harm, until someone does a takeover and things scalate quickly.

For this section, we're gonna rely on two repositories. One which aims to be interactive, and also has a CTF demo in case you don't want to set-up your own, which is wrongsecrets by OWASP. The other one is fake-leaks by a recent project that aims to integrate all secret scanning tools there are available.

There are many, many tools to scan for secrets, and many ways you can do it. You can scan your code, you can scan your IaC, you can scan your whole repository, or you can even have proactive measures. Things that hook to git commands and prevent you from committing them in the first place. And in case you missed anything, or someone is leaking their credentials through a PR, you can even trigger actions afterward.

Semgrep

We are going to start with Semgrep, which is a powerful, customizable lightweight static analysis tool for many languages. Out of the box works like a charm, but if you login, which is free, you have access to the rest of the rules.

wanderer@trg ~ $ semgrep login
Login enables additional proprietary Semgrep Registry rules and running custom policies from Semgrep Cloud Platform.
Opening login at: https://semgrep.dev/login?cli-token=abc12345-6789-0123-4567-89abcdef0123&docker=False&gha=False

Once you've logged in, return here and you'll be ready to start using new Semgrep rules.
Saved login token

	3b9f1a7c8d4e2f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0

in /home/wanderer/.semgrep/settings.yml.
Note: You can always generate more tokens at https://semgrep.dev/orgs/-/settings/tokens

If you use semgrep ci, by default it will scan much more than just secrets. Not to deviate from the main topic, we're going to restrict it to what we want. So we will use two generated rules, one by semgrep which is secrets and has many pro rules, and the other a community ruleset based on a popular tool named gitleaks. There are many tools that have been ported to semgrep, you'll see!

wanderer@trg ~ $ semgrep --config "p/secrets" fake-leaks

┌──── ○○○ ────┐
│ Semgrep CLI │
└─────────────┘

METRICS: Using configs from the Registry (like --config=p/ci) reports pseudonymous rule metrics to semgrep.dev.
To disable Registry rule metrics, use "--metrics=off".
Using configs only from local files (like --config=xyz.yml) does not enable metrics.

More information: https://semgrep.dev/docs/metrics


Scanning 205 files (only git-tracked) with 268 Code rules:

  CODE RULES

  Language      Rules   Files          Origin      Rules
 ─────────────────────────────        ───────────────────
  <multilang>      37     196          Pro rules     216
  yaml              1      27          Community      52
  python           58       4
  php               1       2
  js               36       1
  go               17       1

  SUPPLY CHAIN RULES

  💎 Run `semgrep ci` to find dependency
     vulnerabilities and advanced cross-file findings.


  PROGRESS

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸  99% 0:00:00


┌───────────────────┐
│ 103 Code Findings │
└───────────────────┘
...
fake-leaks/semgrep-rules-examples/detected-google-oauth-access-token.txt
❯❯❱ generic.secrets.security.detected-google-oauth-access-token.detected-google-oauth-access-token
        Google OAuth Access Token detected
        Details: https://sg.run/ox2n

        3┆ "access_token" : "ya29.AHES67zeEn-RDg9CA5gGKMLKuG4uVB7W4O4WjNr-NBfY6Dtad4vbIZ",
...
(continues)
...
┌──────────────┐
│ Scan Summary │
└──────────────┘
Some files were skipped or only partially analyzed.
  Scan was limited to files tracked by git.
  Partially scanned: 6 files only partially analyzed due to parsing or internal Semgrep errors
  Scan skipped: 9 files matching .semgrepignore patterns
  For a full list of skipped files, run semgrep with the --verbose flag.

Ran 150 rules on 196 files: 103 findings.

📢 Too many findings? Try Semgrep Pro for more powerful queries and less noise.
   See https://sg.run/false-positives.

Now let's give it a try to gitleaks port, only showing the summary not to create

semgrep --config "p/gitleaks"
┌──────────────┐
│ Scan Summary │
└──────────────┘
Some files were skipped or only partially analyzed.
  Scan was limited to files tracked by git.
  Scan skipped: 9 files matching .semgrepignore patterns
  For a full list of skipped files, run semgrep with the --verbose flag.

Ran 175 rules on 196 files: 523 findings.

📢 Too many findings? Try Semgrep Pro for more powerful queries and less noise.
   See https://sg.run/false-positives.

We will be using semgrep in other sections as well, since it can parse anything you set your mind to.

2ms

What we like about 2ms is that it will allow you to scan through different platforms that we haven't seen in other tools, such as: Cnfluence, Discord, and Slack servers; Paligo instances; git repositories and filesystem files/folders.

Everytime you see filesystem and local git repository as options you might think it is the same, but don't forget patterns may benefit one scenario more than other.

Here you can see a difference.

Filesystem module:

wanderer@trg ~ $ 2ms filesystem --path fake-leaks
totalitemsscanned: 205
totalsecretsfound: 584

Git module:

wanderer@trg ~ $ 2ms git fake-leaks | less
totalitemsscanned: 275
totalsecretsfound: 649
...

A more obvious example when it comes to deciding whether to pick is the following one, and we think with this one you'll get it.

Leaving only the .git folder from the repo:

wanderer@trg fake-leaks-git $ ls -a
.  ..  .git

Filesystem module:

wanderer@trg ~ $ 2ms filesystem --path fake-leaks-git
18:23:46 INF Folder plugin started
18:23:46 INF Scan completed with empty content

Git module:

wanderer@trg ~ $ 2ms git fake-leaks-git
18:25:12 INF Git plugin started
totalitemsscanned: 275
totalsecretsfound: 649

And it will be a little more obvious when you check the sources of the information from where the secret was obtained. In the case of filesystem they will always come from paths, like source: fake-leaks/test/recipes/30-test_evp_data/evppkey_rsa_common.txt, and for the git module they may come from things like git show c4091a5371939a8471a7cfef58497377cb4ec375:specs/github.json.

Trufflehog

To start with this tool's wizard you can run sudo trufflehog and follow the steps! But if you want a specific command, you can run each of them manually. Check --help to see them all. You can scan from git, to s3/gcs buckets; docker images, CIs, and even your filesystem.

Note: Make sure to append --no-update in order to avoid getting an error while updating to latest version. If you'd like to update you'll need to have root privileges or run it with sudo.

To start, you can start a local folder scan using the filesystem feature aimed at the repository we already downloaded. But we warn you, it will show you a lot of output...

trufflehog --no-update filesystem fake-leaks/

If you want to try a smaller scope, and scan a remote git repository, you can try @trufflesecurity's test_keys repository.

trufflehog --no-update git https://github.com/trufflesecurity/test_keys --only-verified
🐷🔑🐷  TruffleHog. Unearth your secrets. 🐷🔑🐷
...
✅ Found verified result 🐷🔑
Detector Type: URI
Decoder Type: PLAIN
Raw result: https://admin:[email protected]
Commit: 77b2a3e56973785a52ba4ae4b8dac61d4bac016f
Email: counter <[email protected]>
File: keys
Line: 3
Repository: https://github.com/trufflesecurity/test_keys
Timestamp: 2022-06-16 17:27:56 +0000
...

With Trufflehog you can even scan: Docker images, Travis/Circle CI, Syslog, S3/GCS buckets, Jenkins, and more.

Source code

As we've discussed in the Secrets category, the code we write might inadvertently contain secrets, such as credentials or API keys. These can easily go unnoticed, especially after thoroughly debugging a part of an application, which might lead us to forget that we hardcoded sensitive information. Although this is a poor practice, it can happen when collaborating with many people or receiving contributions from external parties who may not be as experienced.

However, secrets are not the only concern. There are also clear vulnerable patterns and well-known vulnerabilities that can be addressed before the code goes into production.

In this section, we will explore a set of tools designed to help us prevent supply-chain attacks by checking dependencies, detecting publicly disclosed vulnerabilities, and more.

Vulnerabilities

When it comes to vulnerabilities, it's a broad topic with many potential entry points within a project. Whether it's the code you wrote, contributions from others, or third-party libraries and dependencies, vulnerabilities can lurk anywhere.

In the develop branch of the @devsecops-toolkit, you'll find tools like Grype and Snyk that are designed to scan for vulnerabilities within a repository. However, our focus will be on exploring other tools that can enhance your security arsenal.

For those interested in expanding their toolkit, the OWASP's Source Code Analysis Tools list is a great resource to explore.

As part of our hands-on testing, we'll be directing these tools towards the NodeJS GOAT repository to see them in action.

git clone https://github.com/OWASP/NodeGoat
cd NodeGoat
npm install

The installation process will take some time. But you can even tell by the looks of npm's install output that this repository isn't any good.

added 962 packages, and audited 1412 packages in 4m

130 vulnerabilities (5 low, 38 moderate, 55 high, 32 critical)

Semgrep

You already know we like Semgrep, but in our previous example we just ran it to scan for secrets. Thing is, I did not tell you how amazing it by default:

wanderer@trg NodeGoat $ semgrep scan .
┌──── ○○○ ────┐
│ Semgrep CLI │
└─────────────┘

Scanning 117 files (only git-tracked) with:

✔ Semgrep OSS
  ✔ Basic security coverage for first-party code vulnerabilities.

✘ Semgrep Code (SAST)
  ✘ Find and fix vulnerabilities in the code you write with advanced scanning and expert security rules.

✘ Semgrep Supply Chain (SCA)
  ✘ Find and fix the reachable vulnerabilities in your OSS dependencies.

💎 Get started with all Semgrep products via `semgrep login`.
✨ Learn more at https://sg.run/cloud.

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸  99% 0:00:01

...
    ❯❱ javascript.browser.security.eval-detected.eval-detected
          Detected the use of eval(). eval() can be dangerous if used to evaluate dynamic content. If this
          content can be input from outside the program, this may be a code injection vulnerability. Ensure
          evaluated content is not definable by external sources.
          Details: https://sg.run/7ope

           33┆ const afterTax = eval(req.body.afterTax);
...

┌──────────────┐
│ Scan Summary │
└──────────────┘
Some files were skipped or only partially analyzed.
  Scan was limited to files tracked by git.
  Partially scanned: 12 files only partially analyzed due to parsing or internal Semgrep errors
  Scan skipped: 1 files larger than 1.0 MB, 36 files matching .semgrepignore patterns
  For a full list of skipped files, run semgrep with the --verbose flag.

Ran 259 rules on 80 files: 38 findings.
💎 Missed out on 886 pro rules since you aren't logged in!
⚡ Supercharge Semgrep OSS when you create a free account at https://sg.run/rules.

As you can see, it has a generic ruleset that scans for any kind of vulnerability inside any project. But most rles are restricted unless you log into the platform, which you can do quick and easy as follows:

wanderer@trg NodeGoat $  semgrep login
Login enables additional proprietary Semgrep Registry rules and running custom policies from Semgrep Cloud Platform.
Opening login at: https://semgrep.dev/login?cli-token=c682a3f1-d734-4b66-bf45-f843b3225dd3&docker=False&gha=False

Once you've logged in, return here and you'll be ready to start using new Semgrep rules.

The followoing image will pop up, and when you press activate you're ready. If this is your first time you will need to register.

Once you've logged in, return here and you'll be ready to start using new Semgrep rules.
Saved login token

 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef

in /home/wanderer/.semgrep/settings.yml.
Note: You can always generate more tokens at https://semgrep.dev/orgs/-/settings/tokens

If we run the scanner again, you will see a difference on the amount of rules ran for this project, and in this case, the findings.

Some files were skipped or only partially analyzed.
  Scan was limited to files tracked by git.
  Partially scanned: 12 files only partially analyzed due to parsing or internal Semgrep errors
  Scan skipped: 1 files larger than 1.0 MB, 36 files matching .semgrepignore patterns
  For a full list of skipped files, run semgrep with the --verbose flag.

Ran 323 rules on 80 files: 41 findings.

Remember you can always go look for a custom community ruleset, or even create your own!

There's another feature, which I think it's the best, which is ci.

wanderer@trg NodeGoat $ semgrep ci


┌────────────────┐
│ Debugging Info │
└────────────────┘

  SCAN ENVIRONMENT
  versions    - semgrep 1.91.0 on python 3.11.2
  environment - running in environment git, triggering event is unknown

  CONNECTION
  Initializing scan ...

If you go to the semgrep platform, inside the Projects folder you will see that a local_scan on NodeGoat is In Progress.

This scan, will eventually enable some of their products, download necessary engines to run, and run them. You will be able to see everything beautifully displayed on the web platform.

  CONNECTION
  Initializing scan (deployment=mockup-org, scan_id=42109875)
  Enabled products: Code, Supply Chain

  ENGINE
Semgrep Pro Engine will be installed in /home/wanderer/.local/pipx/venvs/semgrep/lib/python3.11/site-packages/semgrep/bin/semgrep-core-proprietary

Successfully installed Semgrep Pro Engine (version 1.91.0)!

  Scanning 117 files (only git-tracked) with 1941 Code rules, 3598 Supply Chain rules:

  CODE RULES

  Language      Rules   Files          Origin      Rules
 ─────────────────────────────        ───────────────────
  <multilang>      68      80          Community    1055
  js              219      27          Pro rules     886
  html              1      26
  json              4       8
  yaml             29       4
  dockerfile        4       1


  SUPPLY CHAIN RULES

  Ecosystem   Rules   Files   Lockfiles
 ───────────────────────────────────────────────
  Npm          3598      83   package-lock.json


  Analysis       Rules
 ──────────────────────
  Basic           3029
  Reachability     569


  PROGRESS

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸  99% 0:00:55

As you expect, there's a lot of output.

┌──────────────┐
│ Scan Summary │
└──────────────┘
CI scan completed successfully.
  Found 283 findings (0 blocking) from 22206 rules.
  Uploading scan results
  Finalizing scan
  View results in Semgrep Cloud Platform:
    https://semgrep.dev/orgs/mockup-org/findings?repo=local_scan/NodeGoat&ref=master
    https://semgrep.dev/orgs/mockup-org/supply-chain/vulnerabilities?repo=local_scan/NodeGoat&ref=master
  No blocking findings so exiting with code 0

But as we said, check out the platform!

There, you can apply filters:

See matching findings:

And triage them!

Dependencies

We all rely on them to make our coding lives easier, but sometimes they can bring unexpected issues along for the ride.

When you're building your next big project, those third-party libraries are like trusty sidekicks. But occasionally, they might have vulnerabilities that can sneak into your project and cause trouble. And let's not forget about those sneaky malicious packages that are just waiting to cause a ruckus.

That's why it's crucial to keep an eye on these dependencies and run vulnerability scans. Think of it as a health check-up for your code. By catching these issues early, you can keep your project safe and sound.

We have selected two tools for you to try for this section, the first one is OWASP'S dep-scan, and the second is Dependency-check. We think their name make it pretty obvious they're a great fit for this section, right?

In the branch develop, you will also find Snyk which performs beautifully, not only in this realm but in many others.

OWASP Dependency-check

Yet another OWASP tool to do dependency checking. This one also requires access to several externally hosted resources.

In order to analyze some technology stacks dependency-check may require other development tools to be installed. For this purpose we have only installed a few (yarn, pnpm, go, etc).

The documentation suggests you obtain an National Vulnerability API Key from NIST in order to download the database faster. It really takes only just a minute. Even with the API key the database takes a while.

wanderer@trg ~ $ dependency-check --scan NodeGoat --out . --nvdApiKey 4fde7776-c644-4db0-a135-0b7b2a485317
[INFO] Checking for updates
[INFO] NVD API has 266,355 records in this update
[INFO] Downloaded 10,000/266,355 (4%)
[INFO] Downloaded 20,000/266,355 (8%)
[INFO] Downloaded 30,000/266,355 (11%)

It is mandatory to do it the first time, otherwise you'll get an error saying the database does not exist, since it heavily relies on this.

Afterward, you can run it again

wanderer@trg ~ $ dependency-check --noupdate --scan NodeGoat --out .
# or
dependency-check -n -s NodeGoat --out .

If you were to open the output from a browser, you'll see among the parameters of execution, the following summary.

And for each vulnerable dependency, an excerpt like this one:

You can even expand some of the information like Evidence, and Related dependencies:

It includes recommendation and sources of information from where it grabbed them in the first place to conduct the analysis.

OWASP's dep-scan

So, about this first one, it is actually an official project from OWASP. It focused on known vulnerabilities, advisories, and license restrictions in project dependencies. It can process both local repositories and container images as input, making it perfect for integration.

We are going to show you many tools who have features, based on other projects like cdxgen, to generate Software Bill-of-Materials (BOM). This is like basically creating a list of all the libraries, dependencies, configurations, workflows, your project has in order to get them analyzed.

This is a table showing that it currently supports at the time of writing this document:

Performing a simple scan

I added the explain argument to be able to have a beautiful output and paste it here.

wanderer@trg NodeGoat $ depscan --src $PWD --explain -o reports/nodegoat.json

██████╗ ███████╗██████╗ ███████╗ ██████╗ █████╗ ███╗   ██╗
██╔══██╗██╔════╝██╔══██╗██╔════╝██╔════╝██╔══██╗████╗  ██║
██║  ██║█████╗  ██████╔╝███████╗██║     ███████║██╔██╗ ██║
██║  ██║██╔══╝  ██╔═══╝ ╚════██║██║     ██╔══██║██║╚██╗██║
██████╔╝███████╗██║     ███████║╚██████╗██║  ██║██║ ╚████║
╚═════╝ ╚══════╝╚═╝     ╚══════╝ ╚═════╝╚═╝  ╚═╝╚═╝  ╚═══╝

INFO [2024-10-21 15:33:07,496] To improve performance, cache the bom file and invoke depscan with --bom reports/nodegoat-universal.json instead of -i
INFO [2024-10-21 15:33:13,484] Performing regular scan for /home/wanderer/NodeGoat using plugin universal

                                                       Dependency Scan Results (UNIVERSAL)
╔════════════════════════════════════════════════════════════════╤══════════════════════════════════╤══════════════════╤══════════════╤═════════╗
║ CVE                                                            │ Insights                         │ Fix Version      │ Severity     │   Score ║
╟────────────────────────────────────────────────────────────────┼──────────────────────────────────┼──────────────────┼──────────────┼─────────
║ [email protected]                                                  │ 📓 Indirect dependency         │ 1.2.6            │ CRITICAL    │     9.0 ║
║ └── [email protected] ⬅ CVE-2021-44906                               │                                │                  │             │         ║
╟───────────────────────────────────────────────────────────────────┼────────────────────────────────┼──────────────────┼─────────────┼─────────╢
║ [email protected]                                                     │ 📓 Indirect dependency         │ 4.17.12          │ CRITICAL    │     9.0 ║
║ └── [email protected] ⬅ CVE-2019-10744                                 │                                │                  │             │         ║
╟───────────────────────────────────────────────────────────────────┼────────────────────────────────┼──────────────────┼─────────────┼─────────╢
║ [email protected] ⬅ NPM-1088208                                    │ 📓 Indirect dependency           │ 0.8.5            │ MEDIUM       │     5.0 ║
╟────────────────────────────────────────────────────────────────┼──────────────────────────────────┼──────────────────┼──────────────┼─────────╢
║ [email protected] ⬅ CVE-2017-16042                                   │ 📓 Indirect dependency           │ 1.10.0           │ CRITICAL     │     9.0 ║
╟────────────────────────────────────────────────────────────────┼──────────────────────────────────┼──────────────────┼──────────────┼─────────╢
║ [email protected] ⬅ NPM-1091853                                   │ 📓 Indirect dependency           │ 1.2.11           │ CRITICAL     │     9.0 ║
╟────────────────────────────────────────────────────────────────┼──────────────────────────────────┼──────────────────┼──────────────┼─────────╢
║ [email protected] ⬅ CVE-2019-2391                                     │ 📓 Indirect dependency           │ 1.1.4            │ MEDIUM       │     5.0 ║
╟────────────────────────────────────────────────────────────────┼──────────────────────────────────┼──────────────────┼──────────────┼─────────╢
║ [email protected] ⬅ CVE-2020-7788                                      │ 📓 Indirect dependency           │ 1.3.6            │ HIGH         │     7.5 ║
╟────────────────────────────────────────────────────────────────┼──────────────────────────────────┼──────────────────┼──────────────┼─────────╢
║ [email protected] ⬅ CVE-2020-28282                               │ 📓 Indirect dependency           │ 1.0.0            │ CRITICAL     │     9.0 ║
╟────────────────────────────────────────────────────────────────┼──────────────────────────────────┼──────────────────┼──────────────┼─────────╢
║ node@12-alpine ⬅ CVE-2022-0155                                 │ 📔 Has PoC                       │                  │ MEDIUM       │     6.5 ║
║                                                                │ 🎯 Distro specific               │                  │              │         ║
╚════════════════════════════════════════════════════════════════╧══════════════════════════════════╧══════════════════╧══════════════╧═════════╝
╭──────────────────────────────────── Recommendation ────────────────────────────────────╮
│ 👉 6 out of 206 vulnerabilities requires your attention.                               │
│ You can remediate 70 vulnerabilities by updating the packages using the fix version 👍 │
╰────────────────────────────────────────────────────────────────────────────────────────╯

Risk audit and dependency confusion

There's a --risk-audit argument that enables package risk audit, currenlty working for npm and pypi packages. It weights several risk factors to compute a final score and shows it only if that score surpasses a certain configurable threshold. You can check out how to configure the weights on their docs.

There is also the possibility to use --private-ns to specify the private package namespace that should be checked for dependency confusion type issues where a private package is available on public npm/pypi registry. This is a very common attack vector.

If we were to run a risk audit, with a dependency confusion check, and change a few weights:

wanderer@trg NodeGoat $ PKG_INSTALL_SCRIPTS=4 DEPRECATED=0 depscan --src . --risk-audit --private-ns theredguild

If you pay attention, you can see how risk scores have changed thanks to our tweaks.

Live Operating System Scan

One of the interesting features it has, is the Live OS scan.

By passing -t os, depscan can generate an SBoM for a live operating system or a VM with OS packages and kernel information. Optionally, pass the argument --deep to generate an SBoM with both OS and application packages and to check for application vulnerabilities.

We're going to show you an excerpt of a live os scan from the container you're currently working on.

wanderer@trg ~ $ depscan -t os --deep -i . -o reports/fullos.json --explain

    ██████╗ ███████╗██████╗ ███████╗ ██████╗ █████╗ ███╗   ██╗
    ██╔══██╗██╔════╝██╔══██╗██╔════╝██╔════╝██╔══██╗████╗  ██║
    ██║  ██║█████╗  ██████╔╝███████╗██║     ███████║██╔██╗ ██║
    ██║  ██║██╔══╝  ██╔═══╝ ╚════██║██║     ██╔══██║██║╚██╗██║
    ██████╔╝███████╗██║     ███████║╚██████╗██║  ██║██║ ╚████║
    ╚═════╝ ╚══════╝╚═╝     ╚══════╝ ╚═════╝╚═╝  ╚═╝╚═╝  ╚═══╝

INFO [2024-10-21 15:10:27,649] About to perform deep scan. This could take a while ...
INFO [2024-10-21 15:11:06,152] To improve performance, cache the bom file and invoke depscan with --bom reports/fullos-os.json instead of -i
INFO [2024-10-21 15:11:06,193] About to download the vulnerability database from ghcr.io/appthreat/vdbgz:v5. This might take a while ...
INFO [2024-10-21 15:17:08,655] Performing regular scan for /home/wanderer using plugin os

                                                          Dependency Scan Results (OS)
╔═══════════════════════════════════════════════════════════════╤═══════════════════════════════╤═══════════════════════════╤═══════════╤═══════╗
║ CVE                                                           │ Insights                      │ Fix Version               │ Severity  │ Score ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ [email protected]+deb12u7 ⬅ CVE-2024-6197                        │ ✂ Uninstall candidate         │ 8.9.0                     │ HIGH      │   7.5 ║
║                                                               │ 📓 Local install              │                           │           │       ║
║                                                               │ 📔 Has PoC                    │                           │           │       ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ [email protected]+deb12u3 ⬅ CVE-2024-6923                │ 📓 Local install              │                           │ MEDIUM    │   6.8 ║
║                                                               │ 🎯 Distro specific            │                           │           │       ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ [email protected] ⬅ CVE-2020-1747                                    │ 🧾 Vendor Confirmed           │ 5.4                       │ CRITICAL  │   9.8 ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ [email protected]+deb12u7 ⬅ CVE-2023-27538                       │ ✂ Uninstall candidate         │ 8.0.0                     │ MEDIUM    │   5.5 ║
║                                                               │ 📓 Local install              │                           │           │       ║
║                                                               │ 📔 Has PoC                    │                           │           │       ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ [email protected] ⬅ CVE-2024-34064                                 │ 🧾 Vendor Confirmed           │ 3.1.4                     │ MEDIUM    │   5.4 ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ [email protected] ⬅ CVE-2023-36660                          │ 📓 Local install              │ 3.9.1-2.1                 │ MEDIUM    │   5.0 ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ fdupes@1:2.2.1-1 ⬅ CVE-2022-48682                             │ 📓 Local install              │ 2.2.1-1                   │ MEDIUM    │   5.0 ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ vim@2:9.0.1378-2 ⬅ CVE-2023-48233                             │ ✂ Uninstall candidate         │ 9.0.2116-1                │ LOW       │   2.0 ║
║                                                               │ 📓 Local install              │                           │           │       ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ [email protected]~deb12u2 ⬅ CVE-2023-31437                     │ 🔇 Suppress for containers    │                           │ LOW       │   2.0 ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ [email protected] ⬅ CVE-2022-3515                              │ 📓 Local install              │ 2.2.41                    │ CRITICAL  │   9.8 ║
╟───────────────────────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────┼───────────┼───────╢
║ vim-common@2:9.0.1378-2 ⬅ CVE-2023-5441                       │                               │ 9.0.2010                  │ LOW       │   2.0 ║
╚═══════════════════════════════════════════════════════════════╧═══════════════════════════════╧═══════════════════════════╧═══════════╧═══════╝

                                                                   Next Steps

Below are the vulnerabilities prioritized by depscan. Follow your team's remediation workflow to mitigate these findings.

                                                                Top Priority (OS)
╔═══════════════════════════════════════════════════════════════════════╤═══════════════════════════╤═══════════════════════╤═══════════════════╗
║ Package                                                               │ CVEs                      │ Fix Version           │ Reachable         ║
╟───────────────────────────────────────────────────────────────────────┼───────────────────────────┼───────────────────────┼───────────────────╢
║ [email protected] ⬅ CVE-2024-6345                                     │ CVE-2024-6345             │ 70.0.0                │                   ║
╟───────────────────────────────────────────────────────────────────────┼───────────────────────────┼───────────────────────┼───────────────────╢
║ [email protected]+deb12u7 ⬅ CVE-2024-6197                                │ CVE-2024-6197             │ 8.9.0                 │                   ║
╚═══════════════════════════════════════════════════════════════════════╧═══════════════════════════╧═══════════════════════╧═══════════════════╝

╭──────────────────────────────────── Recommendation ────────────────────────────────────╮
│ 👉 1 out of 468 vulnerabilities requires your attention.                               │
│ You can remediate 67 vulnerabilities by updating the packages using the fix version 👍 │
╰────────────────────────────────────────────────────────────────────────────────────────╯

We've seen enough of this tool! Let's check out the following one.

NodeJS Specific

If you're diving into the world of JavaScript, you're probably using NodeJS for everything from backend services to front-end frameworks. It's everywhere, from Hardhat Framework to quick prototyping with scaffold-eth2. But with great power comes great responsibility, and NodeJS projects can have their fair share of security hiccups.

Let's talk about some of the common attack vectors you might encounter:

• Dependency Confusion: Imagine you're working on a private package, and suddenly, a malicious actor publishes a package with the same name to a public repository. If your setup isn't careful, you might end up pulling in the wrong package. Oops!

• Outdated or Vulnerable Packages: It's easy to forget to update your dependencies. But those old versions might have known vulnerabilities that can be exploited. It's like leaving your front door unlocked because you forgot to upgrade your lock.

• Malicious Packages: Sometimes, a package might look legit but has some nasty surprises inside. Always double-check what you're installing, or you might end up with more than you bargained for.

• Misconfigurations: A simple misconfiguration can open up your app to attacks. It's like leaving a window open when you go on vacation—inviting trouble.

Now, let's introduce some tools that can help you tackle these issues. They all somewhat behave similarly, comparing versions of a project packages to vulnerable packages, except for nodejsscan that can also check code:

RetireJS

A fast and simple scanner. It scans your code and dependencies, giving you a heads-up on what needs updating.

wanderer@trg NodeGoat $ retire
retire.js v5.2.4
Downloading https://raw.githubusercontent.com/RetireJS/retire.js/master/repository/jsrepository-v4.json ...
...

/home/wanderer/NodeGoat/node_modules/nyc/node_modules/handlebars/dist/handlebars.amd.js
 ↳ handlebars 4.0.5
handlebars 4.0.5 has known vulnerabilities:

severity: high; summary: A prototype pollution vulnerability in handlebars is exploitable if an attacker can control the template, retid: 43; https://github.com/wycats/handlebars.js/commit/7372d4e9dffc9d70c09671aa28b9392a1577fd86 https://snyk.io/vuln/SNYK-JS-HANDLEBARS-173692

severity: high; summary: A prototype pollution vulnerability in handlebars is exploitable if an attacker can control the template, issue: 1495, githubID: GHSA-q42p-pg8m-cqh6; https://github.com/advisories/GHSA-q42p-pg8m-cqh6 https://github.com/wycats/handlebars.js/commit/cd38583216dce3252831916323202749431c773e https://github.com/wycats/handlebars.js/issues/1495 https://snyk.io/vuln/SNYK-JS-HANDLEBARS-174183

severity: high; summary: Disallow calling helperMissing and blockHelperMissing directly, retid: 44, CVE: CVE-2019-19919, githubID: GHSA-w457-6q6x-cgp9; https://github.com/wycats/handlebars.js/blob/master/release-notes.md#v430---september-24th-2019 

severity: high; summary: Regular Expression Denial of Service in Handlebars, githubID: GHSA-62gr-4qp9-h98f, CVE: CVE-2019-20922; https://nvd.nist.gov/vuln/detail/CVE-2019-20922

severity: medium; summary: Affected versions of `handlebars` are vulnerable to Denial of Service. The package's parser may be forced into an endless loop while processing specially-crafted templates. This may allow attackers to exhaust system resources leading to Denial of Service.

## Recommendation
Upgrade to version 4.4.5 or later., retid: 75, githubID: GHSA-f52g-6jhx-586p; https://github.com/handlebars-lang/handlebars.js/commit/f0589701698268578199be25285b2ebea1c1e427 severity: high; summary: Versions of `handlebars` prior to 3.0.8 or 4.5.2 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting).

The following template can be used to demonstrate the vulnerability:
    {{#with "constructor"}}
        {{#with split as |a|}}
            {{pop (push "alert('Vulnerable Handlebars JS');")}}
            {{#with (concat (lookup join (slice 0 1)))}}
                {{#each (slice 2 3)}}
                    {{#with (apply 0 a)}}
                        {{.}}
                    {{/with}}
                {{/each}}
            {{/with}}
        {{/with}}
    {{/with}}

Although we don't particularly like the output, at least for its CLI version, we have to admit it is incredibly fast. This is probably because it only looks through locked versions.

Better NPM Audit

Better NPM Audit takes the standard npm audit and kicks it up a notch. It provides more detailed insights and helps you prioritize which vulnerabilities to tackle first.

wanderer@trg NodeGoat $ better-npm-audit audit
╔═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗
║                                                                                       === npm audit security report ===                                                                                       ║
║                                                                                                                                                                                                               ║
║ ID      │ Module               │ Title                                              │ Paths                                              │ Severity │ URL                                               │ Ex. ║
║ 1093814 │ adm-zip              │ Arbitrary File Write in adm-zip                    │ adm-zip                                            │ moderate │ https://github.com/advisories/GHSA-3v6h-hqm4-2rg6 │ n   ║
║ 1097685 │ ajv                  │ Prototype Pollution in Ajv                         │ ajv                                                │ moderate │ https://github.com/advisories/GHSA-v88g-cgmw-v5xw │ n   ║
║ 1094090 │ ansi-regex           │ Inefficient Regular Expression Complexity in       │ ansi-align>ansi-regex                              │ high     │ https://github.com/advisories/GHSA-93q8-gq69-wqmw │ n   ║
║         │                      │ chalk/ansi-regex                                   │ boxen>ansi-regex                                   │          │                                                   │     ║
║         │                      │                                                    │ widest-line>ansi-regex                             │          │                                                   │     ║
║ 1097691 │ async                │ Prototype Pollution in async                       │ async                                              │ high     │ https://github.com/advisories/GHSA-fwr7-v2mv-hh25 │ n   ║
║         │                      │                                                    │ grunt-retire>form-data>async                       │          │                                                   │     ║
║ 1096879 │ babel-traverse       │ Babel vulnerable to arbitrary code execution when  │ nyc>babel-traverse                                 │ critical │ https://github.com/advisories/GHSA-67hx-6x53-jw92 │ n   ║  
╚═════════╧══════════════════════╧════════════════════════════════════════════════════╧════════════════════════════════════════════════════╧══════════╧═══════════════════════════════════════════════════╧═════╝

136 vulnerabilities found. Node security advisories: 1093814, 1097685, 1094090 ...

NodeJsScan

Don't expect this one to run as fast as the previous ones, a least not for huge codebases, since it checks all installed dependencies as well. It is a static analyzer that checks your code for common security issues and vulnerabilities, whether it's a misconfiguration or a sneaky piece of code.

wanderer@trg ~ $ nodejsscan -d NodeGoat -o report.json

[INFO] Running Static Analyzer on - NodeGoat
{
    "files": [
        {
            "/allocations.js": "app/routes/allocations.js"
        },
        {
            "/research.js": "app/routes/research.js"
        }
        ...
    ],
    ...
    "sec_issues": {
        "Open Redirect Vulnerability": [
            {
                "description": "Untrusted user input in redirect() can result in Open Redirect vulnerability",
                "filename": "index.js",
                "line": 72,
                "lines": "    app.post(\"/memos\", isLoggedIn, memosHandler.addMemos);\n\n    // Handle redirect for learning resources link\n    app.get(\"/learn\", isLoggedIn, (req, res) => {\n        // Insecure way to handle redirects by taking redirect url from query string\n        return res.redirect(req.query.url);\n    });\n\n    // Research Page\n    app.get(\"/research\", isLoggedIn, researchHandler.displayResearch);",
                "path": "app/routes/index.js",
                "sha2": "70a4402d7593c404e815aa800f53aa870b09e1b2c940038463c05bacf43def00",
                "tag": "opr",
                "title": "Open Redirect"
            }
        ],
        "Remote Code Injection": [
            {
                "description": "User controlled data in eval() can result in Server Side Injection (SSI) or Remote Code Execution (RCE).",
                "filename": "contributions.js",
                "line": 32,
                "lines": "this.handleContributionsUpdate = (req, res, next) => {\n\n        /*jslint evil: true */\n        // Insecure use of eval() to parse inputs\n        const preTax = eval(req.body.preTax);\n        const afterTax = eval(req.body.afterTax);\n        const roth = eval(req.body.roth);\n\n        /*",
                "path": "app/routes/contributions.js",
                "sha2": "0653948d7144fc9a768e555749cf9ebba4e20d47d5e3466cd4e0cf08d53eb608",
                "tag": "rci",
                "title": "Server Side Injection(SSI) - eval()"
            },
            {
    "total_count": {
        "good": 11,
        "mis": 9,
        "sec": 4
    },
    "vuln_count": {
        "Open Redirect": 1,
        "Server Side Injection(SSI) - eval()": 3
    }

The container version has a web ui, where you can throw repositories into it or clone them directly, and also provides a graphical view of the report. I'd suggest using the cli with a json report unless you need to show the findings summary to an executive.

If you liked this tool, by the same author you can also try njsscan, which is a semantic aware SAST tool that can find insecure code patterns in your Node.js applications.

It uses a simple pattern matcher from libsast and syntax-aware semantic code pattern search tool semgrep.

wanderer@trg ~ $ njsscan NodeGoat
- Pattern Match ████████████████████████████████████████████████████████████ 87
- Semantic Grep  10

njsscan: v0.3.7 | Ajin Abraham | opensecurity.in
...
╒═════════════╤═══════════════════════════════════════════════════════════════════════════════╕
│ RULE ID     │ express_open_redirect                                                         │
├─────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ CWE         │ CWE-601: URL Redirection to Untrusted Site ('Open Redirect')                  │
├─────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ OWASP-WEB   │ A1: Injection                                                                 │
├─────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ DESCRIPTION │ Untrusted user input in redirect() can result in Open Redirect vulnerability. │
├─────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ SEVERITY    │ ERROR                                                                         │
├─────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ FILES       │ ╒════════════════╤═════════════════════════════════════╕                      │
│             │ │ File           │ NodeGoat/app/routes/index.js        │                      │
│             │ ├────────────────┼─────────────────────────────────────┤                      │
│             │ │ Match Position │ 16 - 43                             │                      │
│             │ ├────────────────┼─────────────────────────────────────┤                      │
│             │ │ Line Number(s) │ 72                                  │                      │
│             │ ├────────────────┼─────────────────────────────────────┤                      │
│             │ │ Match String   │ return res.redirect(req.query.url); │                      │
│             │ ╘════════════════╧═════════════════════════════════════╛                      │
╘═════════════╧═══════════════════════════════════════════════════════════════════════════════╛

Container / Images

First, we have to do a proper differentiation about the various methods to identify and address security issues and misconfigurations in containers, along with examples of how to retrieve or generate each case.

1. Live Container Scanning: This involves scanning the container while it is running, similar to how you would perform security checks on a live operating system. For example, you can use a tool from within the container, running it locally systerm wide.

2. Software Bill of Materials (SBOM) Analysis: By extracting and analyzing the SBOM, you can gain insights into the components and dependencies within a container. For instance, you can generate an SBOM using syft with the command: syft <image-name> -o json > sbom.json.

3. Image Layer Analysis: To save a container image and its layers to disk, you can use Docker's save command. This command exports the image and its layers into a tarball, which can then be examined in detail. For example, you can save an image with the command: docker save <image-name> -o <image-name>.tar. Once saved, you can use tools like dive to analyze the image layers by first loading the tarball with docker load -i <image-name>.tar and then running dive <image-name>.

4. Remote Container Scanning: This approach involves scanning containers that are hosted remotely. For example, you can use trivy to scan a remote container image with the command: trivy image theredguild/sampleRepo:latest.

5. Repository Scanning: Scanning a repository that contains container images or Dockerfiles can help identify security issues before the containers are built and deployed. You can use semgrep to scan a local repository with the command: semgrep --config "p/dockerfile" --path localRepo.

Now, let's take a more practical approach to see these examples better.

Dockerfile linters and more

Linting is a crucial step in development, since it can bring many insights and best practices that can help us avoid commiting horrible mistakes.

The first tool we've tested and found was Hadolint, which is not included now since it was apparently rewritten in Semgrep and can be easily replaced by a rule. Either way, we suggest you try Hadolint for itself to double check.

Semgrep

Here you can run Selected rules from Hadolint:

semgrep --config "p/dockerfile" Dockerfile

You can also use some more rules like the following ones!

Security checks for docker-compose configuration files:

semgrep --config "p/docker-compose" 

Security checks for kubernetes configuration files:

semgrep --config "p/kubernetes"

Since you've already seen many examples of this tool, I'm not going to show many examples, nor output, and skip to the next one.

Dockle

This is an amazing and widely used linter to scan images, but it only scans images. In order to scan you either need to provide an image name and tag, or save it to a tar file and then scan it locally.

Here's an example from their repository:

wanderer@trg DevSecOps-toolkit $ dockle goodwithtech/test-image:v1
FATAL	- CIS-DI-0009: Use COPY instead of ADD in Dockerfile
	* Use COPY : /bin/sh -c #(nop) ADD file:81c0a803075715d1a6b4f75a29f8a01b21cc170cfc1bff6702317d1be2fe71a3 in /app/credentials.json
FATAL	- CIS-DI-0010: Do not store credential in environment variables/files
	* Suspicious filename found : app/credentials.json (You can suppress it with "-af credentials.json")
	* Suspicious ENV key found : MYSQL_PASSWD on /bin/sh -c #(nop)  ENV MYSQL_PASSWD=password (You can suppress it with --accept-key)
FATAL	- DKL-DI-0005: Clear apt-get caches
	* Use 'rm -rf /var/lib/apt/lists' after 'apt-get install|update' : /bin/sh -c apt-get update && apt-get install -y git
FATAL	- DKL-LI-0001: Avoid empty password
	* No password user found! username : nopasswd
WARN	- CIS-DI-0001: Create a user for the container
	* Last user should not be root
INFO	- CIS-DI-0005: Enable Content trust for Docker
	* export DOCKER_CONTENT_TRUST=1 before docker pull/build
INFO	- CIS-DI-0006: Add HEALTHCHECK instruction to the container image

Scan an image file. Note you won't be able to use docker inside our container since we don't have installed docker in docker. But you can save it from your host, and transfer it in any way you desire.

theredguild@home $ docker save python:3.4-alpine -o python.tar
theredguild@home $ dockle --input python.tar
DevSecOps-toolkit on workshop-minimal [$]
❯ docker save devsecops-toolkit:latest -o devsecops.tar
❯ dockle --input devsecops.tar
FATAL	- DKL-DI-0001: Avoid sudo command
	* Avoid sudo in container : RUN |26 USERNAME=wanderer GROUPNAME=trg USER_UID=1000 USER_GID=1000 T_2MS=3.10.0 T_CHECKOV=3.2.267 T_CLAIR=4.8.0 T_CLOUDSPLAINING=0.7.0 T_DEPCHECK=10.0.4 T_DETECT_SECRETS=1.5.0 T_DOCKLE=0.4.14 T_GITXRAY=1.0.16 T_GITLEAKS=8.21.0 T_GRYPE=0.82.1 T_HADOLINT=2.12.0 T_KICS=2.1.3 T_LEGITIFY=1.0.11 T_NODEJSSCAN=3.7 T_RETIRE=5.2.4 T_SCOUTSUITE=5.14.0 T_SEMGREP=1.91.0 T_SNYK=1.1293.1 T_TRIVY=0.56.2 T_TRUFFLEHOG=3.82.8 T_DEPSCAN=5.2.6 T_OCTOSCAN=0.1.1 /bin/sh -c apt-get update && apt-get install -y     curl     wget     git     build-essential     python3     python3-venv     python3-dev     python3-pip     gnupg     dirmngr     ca-certificates     libssl-dev     zlib1g-dev     libbz2-dev     libreadline-dev     libsqlite3-dev     libffi-dev     liblzma-dev     zsh     pipx     sudo     make     vim     unzip     default-jre     yarn     fdupes     && rm -rf /var/lib/apt/lists/* # buildkit

(many like these because I used too many sudos apparently)

INFO	- CIS-DI-0005: Enable Content trust for Docker
	* export DOCKER_CONTENT_TRUST=1 before docker pull/build
INFO	- CIS-DI-0006: Add HEALTHCHECK instruction to the container image
	* not found HEALTHCHECK statement
INFO	- CIS-DI-0008: Confirm safety of setuid/setgid files
	* setuid file: urwxr-xr-x usr/bin/newgrp
	* setgid file: grwxr-xr-x usr/bin/chage
	* setgid file: grwxr-xr-x usr/bin/expiry
	* setuid file: urwxr-xr-x usr/bin/chsh
	* setuid file: urwxr-xr-x usr/bin/umount
	* setuid file: urwxr-xr-x usr/bin/sudo
	* setuid file: urwxr-xr-x usr/bin/mount
	* setuid file: urwxr-xr-x usr/lib/openssh/ssh-keysign
	* setgid file: grwxr-xr-x usr/sbin/unix_chkpwd
	* setuid file: urwxr-xr-x usr/bin/passwd
	* setuid file: urwxr-xr-x usr/bin/su
	* setuid file: urwxr-xr-x usr/bin/gpasswd
	* setuid file: urwxr-xr-x usr/bin/chfn
	* setgid file: grwxr-xr-x usr/bin/ssh-agent
	* setuid file: urwxr-xr-- usr/lib/dbus-1.0/dbus-daemon-launch-helper
INFO	- DKL-LI-0003: Only put necessary files
	* Suspicious directory : home/wanderer/.local/pipx/.cache
	* Suspicious directory : home/wanderer/.asdf/plugins/nodejs/.git
	* Suspicious directory : home/wanderer/.asdf/plugins/golang/.git
	* Suspicious directory : home/wanderer/.asdf/.git
	* Suspicious directory : home/wanderer/.asdf/plugins/nodejs/.node-build/.git
	* unnecessary file : home/wanderer/.asdf/installs/golang/1.23.2/go/src/crypto/internal/boring/Dockerfile
	* Suspicious directory : src/gh-workflow-auditor/.git
	* Suspicious directory : home/wanderer/.npm
	* unnecessary file : home/wanderer/.asdf/installs/golang/1.23.2/go/src/crypto/internal/nistec/fiat/Dockerfile

Vulnerabilities

Container security encompasses more than just code vulnerabilities; it includes configurations, dependencies, and runtime behaviors. Here are key tools to help secure your containers:

• Trivy: A comprehensive scanner for vulnerabilities, misconfigurations, secrets, and SBOMs in containers, Kubernetes, and more. It's fast and user-friendly, making it ideal for quick security assessments.

• Clair: Conducts static analysis of container images, identifying vulnerabilities by comparing them against a database. It's well-suited for CI/CD integration to ensure images are secure before deployment.

• Falco: Offers runtime security by monitoring container behavior for anomalies. It alerts on suspicious activities, making it crucial for real-time security monitoring.

• Snyk: Specializes in open source dependencies, container images, and Kubernetes security. It integrates with development workflows, providing actionable insights and automated fixes, ideal for DevOps teams.

• Grype: A straightforward tool for scanning container images for vulnerabilities. It provides detailed reports and is easily integrated into CI/CD pipelines for automated checks.

• Checkov: A static code analysis tool for infrastructure as code (IaC). It helps detect misconfigurations in container orchestration files, ensuring compliance and security best practices.

Each tool has its strengths: Trivy and Grype for scanning, Clair for static analysis, Falco for runtime monitoring, Snyk for development integration, and Checkov for IaC security. Choose based on your specific security needs and workflow requirements.

They have all been integrated into the develop branch of @theredguild/devsecops-toolkit. However, for the minimal-workshop, we have only included Trivy and Checkov. Since Checkov needs a Bridgecrew platform API key to scan images, and we've already used it once, we are going to focus on Trivy.

Trivy

Trivy is an exceptional tool, we can't explain how many features, and configurations it has. You should check it out by yourself. For example, look at the parameters you can pass to the image command. It even comes with great examples.

trivy image
...

Examples:
  # Scan a container image
  $ trivy image python:3.4-alpine

  # Scan a container image from a tar archive
  $ trivy image --input ruby-3.1.tar

  # Filter by severities
  $ trivy image --severity HIGH,CRITICAL alpine:3.15

  # Ignore unfixed/unpatched vulnerabilities
  $ trivy image --ignore-unfixed alpine:3.15

  # Scan a container image in client mode
  $ trivy image --server http://127.0.0.1:4954 alpine:latest

  # Generate json result
  $ trivy image --format json --output result.json alpine:3.15

  # Generate a report in the CycloneDX format
  $ trivy image --format cyclonedx --output result.cdx alpine:3.15

Normally, you would use trivy to scan images without the need to input a file. But since we don´t want to run docker inside this container, you can feed it an image file.

wanderer@trg DevSecOps-toolkit $ trivy image --input python.tar
2024-10-21T22:37:58Z	INFO	[vuln] Vulnerability scanning is enabled
2024-10-21T22:37:58Z	INFO	[secret] Secret scanning is enabled
2024-10-21T22:37:58Z	INFO	[secret] If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2024-10-21T22:37:58Z	INFO	[secret] Please see also https://aquasecurity.github.io/trivy/v0.56/docs/scanner/secret#recommendation for faster secret detection
2024-10-21T22:37:58Z	INFO	Detected OS	family="alpine" version="3.9.2"
2024-10-21T22:37:58Z	INFO	[alpine] Detecting vulnerabilities...	os_version="3.9" repository="3.9" pkg_num=28
2024-10-21T22:37:58Z	INFO	Number of language-specific files	num=1
2024-10-21T22:37:58Z	INFO	[python-pkg] Detecting vulnerabilities...
2024-10-21T22:37:58Z	WARN	This OS version is no longer supported by the distribution	family="alpine" version="3.9.2"
2024-10-21T22:37:58Z	WARN	The vulnerability detection may be insufficient because security updates are not provided

python.tar (alpine 3.9.2)

Total: 3 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 2)

┌──────────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┬────────────────────────────────────────────────────────���─────┐
│   Library    │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version │                            Title                             │
├──────────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ expat        │ CVE-2018-20843 │ HIGH     │ fixed  │ 2.2.6-r0          │ 2.2.7-r0      │ expat: large number of colons in input makes parser consume  │
│              │                │          │        │                   │               │ high amount...                                               │
│              │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2018-20843                   │
├──────────────┼────────────────┼──────────┤        ├───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ libbz2       │ CVE-2019-12900 │ CRITICAL │        │ 1.0.6-r6          │ 1.0.6-r7      │ bzip2: out-of-bounds write in function BZ2_decompress        │
│              │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2019-12900                   │
├──────────────┼────────────────┼──────────┤        ├───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ musl         │ CVE-2019-14697 │ CRITICAL │        │ 1.1.20-r4         │ 1.1.20-r5     │ musl libc through 1.1.23 has an x87 floating-point stack     │
│              │                │          │        │                   │               │ adjustment im ......                                         │
│              │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2019-14697                   │
└──────────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────┴──────────────────────────────────────────────────────────────┘
2024-10-21T22:37:58Z	INFO	Table result includes only package filenames. Use '--format json' option to get the full path to the package file.

And here the results for python-pkg. I trimmed and separated them as usual.

Python (python-pkg)

Total: 6 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 5, CRITICAL: 0)

┌───────────────────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┬─────────────────────────────────────────────────────────────┐
│        Library        │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version │                            Title                            │
├───────────────────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ pip (METADATA)        │ CVE-2019-20916 │ HIGH     │ fixed  │ 19.0.3            │ 19.2          │ python-pip: directory traversal in _download_http_url()     │
│                       │                │          │        │                   │               │ function in src/pip/_internal/download.py                   │
│                       │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2019-20916                  │
│                       ├────────────────┤          │        │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│                       │ CVE-2021-3572  │          │        │                   │ 21.1          │ python-pip: Incorrect handling of unicode separators in git │
│                       │                │          │        │                   │               │ references                                                  │
│                       │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2021-3572                   │
│                       ├────────────────┼──────────┤        │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│                       │ CVE-2023-5752  │ MEDIUM   │        │                   │ 23.3          │ pip: Mercurial configuration injectable in repo revision    │
│                       │                │          │        │                   │               │ when installing via pip                                     │
│                       │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2023-5752                   │
├───────────────────────┼────────────────┼──────────┤        ├───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ setuptools (METADATA) │ CVE-2022-40897 │ HIGH     │        │ 40.8.0            │ 65.5.1        │ pypa-setuptools: Regular Expression Denial of Service       │
│                       │                │          │        │                   │               │ (ReDoS) in package_index.py                                 │
│                       │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2022-40897                  │
│                       ├────────────────┤          │        │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│                       │ CVE-2024-6345  │          │        │                   │ 70.0.0        │ pypa/setuptools: Remote code execution via download         │
│                       │                │          │        │                   │               │ functions in the package_index module in...                 │
│                       │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2024-6345                   │
├───────────────────────┼────────────────┤          │        ├───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ wheel (METADATA)      │ CVE-2022-40898 │          │        │ 0.33.1            │ 0.38.1        │ python-wheel: remote attackers can cause denial of service  │
│                       │                │          │        │                   │               │ via attacker controlled input...                            │
│                       │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2022-40898                  │
└───────────────────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────┴─────────────────────────────────────────────────────────────┘

Cloud

In the minimal-workshop, we decided to skip cloud tools to avoid the risk of sharing sensitive API keys or credentials in a potentially insecure environment. However, if you're diving into the develop branch of the devsecops-toolkit, you'll find a wide array of cloud security tools ready to explore.

Let's talk about some of these tools. CloudSploit is great for continuous monitoring of your cloud infrastructure, helping you spot misconfigurations before they become a problem. Cloudsplaining takes a deep dive into your AWS IAM policies, ensuring your permissions are as tight as they should be. Then there's Prowler, which is like your cloud security Swiss Army knife, offering a wide range of checks for AWS environments.

KICS (Keeping Infrastructure as Code Secure) is perfect for scanning your IaC files to catch security issues early in the development process. ScoutSuite provides a comprehensive security assessment of your cloud environment, supporting multiple cloud providers.

Each tool has its strengths, so it's worth trying them out to see which fits your needs best. Whether you're looking for detailed policy analysis or broad infrastructure checks, there's a tool in the toolkit for you!

Outro

This section is yet to be written, but will cover some general advice revolving around all areas where you can harden your operational security.