securecodebox / documentation

This repo contains the complete SCB project documentation.

OWASP secureCodeBox

secureCodeBox is a kubernetes based, modularized toolchain for continuous security scans of your software project. Its goal is to orchestrate and easily automate a bunch of security-testing tools out of the box.

Overview

• OWASP secureCodeBox
  • Overview
  • Purpose of this Project
  • Quickstart
  • Architecture Overview
  • Upgrading
  • License
  • Community
  • Contributing
  • Sponsors
  • Author Information

For additional documentation aspects please have a look at our documentation website:

Purpose of this Project

The typical way to ensure application security is to hire a security specialist (aka penetration tester) at some point in your project to check the application for security bugs and vulnerabilities. Usually, this check is done at a later stage of the project and has two major drawbacks:

1. Nowadays, a lot of projects do continuous delivery, which means the developers deploy new versions multiple times each day. The penetration tester is only able to check a single snapshot, but some further commits could introduce new security issues. To ensure ongoing application security, the penetration tester should also continuously test the application. Unfortunately, such an approach is rarely financially feasible.
2. Due to a typically time boxed analysis, the penetration tester has to focus on trivial security issues (low-hanging fruit) and therefore will probably not address the serious, non-obvious ones.

With the secureCodeBox we provide a toolchain for continuous scanning of applications to find the low-hanging fruit issues early in the development process and free the resources of the penetration tester to concentrate on the major security issues.

The purpose of secureCodeBox is not to replace the penetration testers or make them obsolete. We strongly recommend to run extensive tests by experienced penetration testers on all your applications.

Important note: The secureCodeBox is no simple one-button-click-solution! You must have a deep understanding of security and how to configure the scanners. Furthermore, an understanding of the scan results and how to interpret them is also necessary.

There is a German article about Security DevOps – Angreifern (immer) einen Schritt voraus in the software engineering journal OBJEKTSpektrum.

Quickstart

You can find resources to help you get started on our documentation website including instruction on how to install the secureCodeBox and guides to help you run your first scans with it.

Architecture Overview

Upgrading

For the steps required for upgrading your secureCodeBox installation, see Upgrading.

License

Code of secureCodeBox is licensed under the Apache License 2.0.

Community

You are welcome, please join us on... 👋

• GitHub Discussions (Questions & Feedback)
• GitHub Issues (Bugs & Feature Requests)
• Mastodon

secureCodeBox is an official OWASP project.

Contributing

Contributions are welcome and extremely helpful 🙌 Please have a look at Contributing

Thanks to Our Awesome Contributors

Sponsors

Author Information

Sponsored and maintained by iteratec GmbH - secureCodeBox.io

documentation's Issues

Broken link in documentation

The page https://docs.securecodebox.io/docs/api/crds/scan/ refers to https://docs.securecodebox.io/docs/crds/cascading-rule which gives a 404 Error.

Swap the H1 and H2 for better SEO

We should swap the H1 and H2 because the H1 is more important for the crawler. The H1 should contain "Automated Security Testing" and not the H2.

This was an advise from our marketing specialist.

Check docs for all scanners for correctness: Gitleaks

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Check docs for all scanners for correctness: Git Repo Scanner

Part of the effort to sanity-check all documentation.

Titles are not visible in light mode

All <h1> headers take a white color in the light mode theme. They are as a result not visible.

Write a Documentation Style Guide

As a developer I want a style guide so that I know how to format the Markdown in documentation.

Acceptance criteria:

• There is a section about this topic under the contribution section.
• There is defined what markup we use for which entity in text.

Index Sites for Sections

At the moment we have no index sites for sections like How-Tos: https://docs.securecodebox.io/docs/how-tos/. This gos to an 404. But it would be nice to refer to a whole section with an URL.

Check docs for all scanners for correctness: AngularJS CSTI Scanner

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Check docs for all scanners for correctness: nuclei

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

📚 Add a documentation style guide

📚 Document a security threat modell for the secureCodeBox Project

As a secureCodeBox user i want to know more about the security aspects of the secureCodeBox itself. Therfore i would like to find a documented threat modell of the project which lists all known threats and countermeasures.

Topics which could be interesting therefore:

• security aspects of the underlying SCB architecture
• data flow and data processing within the SCB Operator and all components (storage, scanner, hooks)
• kubernetes security aspects like network security policies , pod security policies, security Context, ressource limits and namespace quota and their impact to the secureCodeBox
• authentication and authorization of used service accounts and their impact in multi tenancy clusters
• CICD security of the SCB Project (SDLC)

To give you an impression how such and threat modell can be documented here a good example from the OAUTH2 spec: https://tools.ietf.org/html/rfc6819

📚 Add a dedicated “Testing” section and explain the project test strategy

As contributer i would like to to know how the test strategy of the project is implemented, how to use and extend it.

Acceptance Criteria

• New Test Concept Guide is documented here: https://docs.securecodebox.io/docs/contributing/test-concept
• It is documented where to implement/find unit-tests, integration-tests.
• It is documented how to use/start unit-tests, integration-tests with make

** further informations**

Reference to common patterns and best practice strategies like: https://martinfowler.com/articles/practical-test-pyramid.html

** topics to cover**

• Unit Tests for core components like the operator (Go tests)
  • Operator #250
• Unit Tests for secureCodeBox modules like sdk, hooks, scanner... (jest an pytest)
  • Scanners #250
  • Hooks #258
• Integration Tests
  • Scanners #250
  • Hooks #258
• Introduction and Guideline to the Test Concept (reference to fowler) - What do we use (unit, integration), what is important (speed) #259

Redirect via 302 from www.securecodebox.io

For SEO it is better to do a 302 redirect from docs.securecodebox.io -> www.securecodebox.io.

Document Vagrant Setup

Extend the installation doc with info about the Vagra setup.

Add OWASP Section to securecodebox.io

Add OWASP Logo and short description (see bewlow) to "About us" Section:

Content:
OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security.

📚 Write a Contribution Guide: How to integrate a new Hook

As a new secureCodeBox developer i would like get additional help (documentation) about how to technically integrate a new hook into the secureCodeBox.

Add OWASP Link

We should add a link to our OWASP-Project site: https://owasp.org/www-project-securecodebox/

Check docs for all scanners for correctness: Kubehunter

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Check docs for all scanners for correctness: Typo3scan

Part of the effort to sanity-check all documentation.

Check docs for all scanners for correctness: ncrack

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Keeping docs complete and up-to-date

The documentation is in some place very out of date or incomplete. To give a few examples:

• Incomplete:

• automatically-repeating-scans.md #127
• scanning-web-applications.md #130
• conventions.md

• Out-of-date #126 :

• integrating-a-scanner.md incorrect tree
• integrating-a-hook.md incorrect tree
• scanners.md does not include nuclei, whatweb, typo3scan

What are the guidelines concerning keeping the documentation up-to-date? How is decided what topics may be published as incomplete? How are newly implemented features required to update the docs too?

This issue is in no way a shame and blame post, but I'd just like to get some more insight into how this process is currently maintained.

Maybe it would be a good idea to make issues for the currently incorrect documentation so that contributors can pick them up more easily.

📚Write How to: create scheduled scans

Write the following missing docs:

https://docs.securecodebox.io/docs/how-tos/automatically-repeating-scans

:books: Write a blog post about how the core development team works

To engage more community interaction, we want to start by writing a blog post about how our core development team works internally.
It should include:

• Our general approach (Sprints, Agile)
• Our tools and ways of communication
• Our retro/review/planning session
• Call for community engagement

Adjustment to the site header to highlight the OWASP logo

@Weltraumschaf how about this adjustment to the site header to highlight the OWASP logo?

Text:
secureCodeBox – an OWASP project – provides an automated and scalable Open-Source solution that integrates multiple security scanners with a simple and lightweight interface – for continuous and automated security testing.

Originally posted by @ftitze in #133 (comment)

💻 Consider moving from Netlify back to GitHub Pages

In our last Retrospective we raised this issue. Some Background:

• Netlify is great because it supports multi branch builds
• Downside of Netlify: We have to pay lot of money to give more than one person access to the logfiles. That hinders fats development.
• With GitHub OTOH we already have a legal agreement we need for GDPR.

Add a search to the docs

Based on this documentation https://v2.docusaurus.io/docs/search we should try to integrate a search function within our docs.

Check docs for all scanners for correctness: Kubeaudit

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Enable the Versions feature for our documentation framework

We will release new secureCodeBox V2 versions from time to time and our documentation should be able to reference the different release versions also with the corresponding documentation version. Thankfully our documentation framework already has a solution for that: https://v2.docusaurus.io/docs/versioning and we should adapt that.

📚Add a dedicated Installation section with different target 🎯 environments

Add install instructions for different environments like:

• Bin/install / Helm ⛑

• Kustomize

• Vagrant

• Minikube

• Docker for Desktop

• Rancher v2

• K3S / K0S

• GKE / AKS / EKS

Broken Edit Links for Pages copied from the secureCodeBox repository

When you visit a page on the web site that is copied from the secureCodeBox/secureCodeBox repository and click "Edit this page" one gets a "Page not found" Error. An example can be any scanner

We should add a variable to the config with the url of the secureCodeBox/secureCodeBox repository and use it on all pages that are copied over so people can edit them.

Check docs for all scanners for correctness: Trivy

Part of the effort to sanity-check all documentation.

Integrate the ADRs from Main Repo

In our main Repo we have some ADRs. These should belinked into our documentation.

Alerting of Failed Builds

At the moment there is no alerting when the documentation builds failed. Just this week we hadn't updated doc because some links were broken and the master buildfailed.

IMHO the build pipeline should send a notification.

Documentation Build Fails Due to Broken Links

12:03:41 PM: [en] Creating an optimized production build...
12:03:41 PM: [Local Search] [INFO]: The documentation is not versioned (/opt/build/repo/versions.json does not exist).
12:03:42 PM: [info] [webpackbar] Compiling Client
12:03:42 PM: [info] [webpackbar] Compiling Server
12:04:47 PM: [success] [webpackbar] Client: Compiled successfully in 1.07m
12:04:58 PM: [success] [webpackbar] Server: Compiled successfully in 1.26m
12:05:11 PM: [Local Search] [INFO]: Gathering documents
12:05:11 PM: [Local Search] [INFO]: Parsing documents
12:05:22 PM: [Local Search] [INFO]: Building index
12:05:23 PM: [Local Search] [INFO]: Writing index to disk
12:05:23 PM: [Local Search] [INFO]: Index written to disk, success!
12:05:23 PM: Unable to build website for locale "en".
12:05:23 PM: Error: Docusaurus found broken links!
12:05:23 PM:
12:05:23 PM: Please check the pages of your site in the list below, and make sure you don't reference any path that does not exist.
Note: it's possible to ignore broken links with the 'onBrokenLinks' Docusaurus configuration, and let the build pass.
12:05:23 PM: Exhaustive list of all broken links found:
12:05:23 PM:
12:05:23 PM: - On source page path = /docs/architecture/adr/adr_0009:
12:05:23 PM:  -> linking to (https://docs.securecodebox.io/docs/scanners/gitleaks) (resolved as: /docs/architecture/adr/(https://docs.securecodebox.io/docs/scanners/gitleaks))
12:05:23 PM:  -> linking to (https://github.com/returntocorp/semgrep) (resolved as: /docs/architecture/adr/(https://github.com/returntocorp/semgrep))
12:05:23 PM:  -> linking to (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) (resolved as: /docs/architecture/adr/(https://kubernetes.io/docs/concepts/workloads/pods/init-containers/))
12:05:23 PM:  -> linking to (https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) (resolved as: /docs/architecture/adr/(https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-initialization/)
12:05:23 PM:
12:05:23 PM:  at Object.reportMessage (/opt/build/repo/node_modules/@docusaurus/utils/lib/index.js:357:19)
12:05:23 PM:  at Object.handleBrokenLinks (/opt/build/repo/node_modules/@docusaurus/core/lib/server/brokenLinks.js:142:17)
12:05:23 PM:  at async buildLocale (/opt/build/repo/node_modules/@docusaurus/core/lib/commands/build.js:160:5)
12:05:23 PM:  at async tryToBuildLocale (/opt/build/repo/node_modules/@docusaurus/core/lib/commands/build.js:32:20)
12:05:23 PM:  at async Object.mapAsyncSequencial (/opt/build/repo/node_modules/@docusaurus/utils/lib/index.js:312:24)
12:05:23 PM:  at async build (/opt/build/repo/node_modules/@docusaurus/core/lib/commands/build.js:68:25)
12:05:24 PM: npm ERR! code ELIFECYCLE
12:05:24 PM: npm ERR! errno 1
12:05:24 PM: npm ERR! [email protected] build: `docusaurus build`
12:05:24 PM: npm ERR! Exit status 1
12:05:24 PM: npm ERR!
12:05:24 PM: npm ERR! Failed at the [email protected] build script.
12:05:24 PM: npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
12:05:24 PM: npm ERR! A complete log of this run can be found in:
12:05:24 PM: npm ERR! /opt/buildhome/.npm/_logs/2021-10-18T10_05_24_086Z-debug.log
12:05:24 PM: 
12:05:24 PM: ────────────────────────────────────────────────────────────────
12:05:24 PM:  "build.command" failed 
12:05:24 PM: ────────────────────────────────────────────────────────────────
12:05:24 PM: 
12:05:24 PM: Error message
12:05:24 PM: Command failed with exit code 1: npm install; npm run build;
12:05:24 PM: 
12:05:24 PM: Error location
12:05:24 PM: In Build command from Netlify app:
12:05:24 PM: npm install; npm run build;

Check docs for all scanners for correctness: SSH

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Check docs for all scanners for correctness: screenshooter

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

📚 Write How-To: Web Application Scanning

Write the User Guide "How-To Web App Scanning" (ZAP, Juice Shop)

Autogenerate the Sidebar

At the moment we have a static sidebar and there we add the scanner and hooks documentation via build script. But this concept is not sufficient any more for the use case to add the ADRs and other docs from the main repository.

📣 Write Blog Post why version 2

To introduce users to the changes made to the secureCodeBox in version 2, a blog post should be written to introduce and explain the motivation behind the changes.

Add DCO to this Repository

We need a proper license and DCO in this repo as well as in the main repo.

Check docs for all scanners for correctness: Nikto

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Restructure Docs

We updated our goals how we'd like our docs to be structured.
This new structure is described here: https://github.com/secureCodeBox/documentation#how-the-documentation-is-structured-and-organized

So the docs (both sidebar and content) should be slightly restructured to this new structure.

Versioning of the Documentation

Since we plan major breaking changes (v3) this impacts also the documentation. We decided some time ago to maintain documentation for older versions.

Docusaurus provides this as a feature, but we have to combine this with our build script which pulls in documentation markdown files from the main repo.

🐛 ZAP Scanner Page not showing

The ZAP Page is missing in the Scan Page and also seems to be missing completely (https://docs.securecodebox.io/docs/scanners/ZAP returns a 404).

When I build the site locally (npm start or npm run build) it shows up like expected.

@rseedorff can you see any errors in the netlify build log?

Check docs for all scanners for correctness: SSLyze

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Link in ATOM Feed is broken

The link to the first post (https://securecodebox.io/blog/2020/09/08/blinmaker) results in 404.

The URL misses the docs. subdomain. The URL should be https://docs.securecodebox.io/blog/2020/09/08/blinmaker

Check docs for all scanners for correctness: nmap

Part of the effort to sanity-check all documentation.

Scanner Sanity-Check:

• Sanity Check if the existing documentation is understandable and useful for you as a (first time) user
• Ensure the general chart/scanner description is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.chartAboutSection" -}}
• Ensure the baseline scanner configuration is up to date and consistent to other scanners
  • ./scanner/NAME/.helm-docs.gotmpl -> {{- define "extra.scannerConfigurationSection" -}}
• Ensure there is at minimum one scan example with the following files:
  • Example Scan File: ./scanner/NAME/examples/EXAMPLE-NAME/scan.yaml
  • Example Scan Result File: ./scanner/NAME/examples/EXAMPLE-NAME/findings.yaml
• Ensure the docs files are generated correct and are up to date (sometimes the automated helm-docs update via SCB-Bot failed to update the docs correctly)
  • ./scanner/NAME/readme.md
  • ./scanner/NAME/docs/README.ArtifactHub.md
  • ./scanner/NAME/docs/README.DockerHub-Parser.md
  • Optional, only if a dedicated scanner image is defined:./scanner/NAME/docs/README.DockerHub-Scanner.md

Additional Context:

• SCB Scanner Documentation (based on the above markdown files): https://docs.securecodebox.io/docs/scanners
• SCB DockerHub Images (with description based on docs for each image): https://hub.docker.com/u/securecodebox/
• SCB Artifact Helm Charts: https://artifacthub.io/packages/search?org=securecodebox

Write How-To: Repeating Scans on a Schedule

📚 Write a Contribution Guide: How to integrate a new Security Scanner

As a new secureCodeBox developer i would like get additional help (documentation) about how to technically integrate a new security scanner into the secureCodeBox.

Add a Getting started User Guide

As a new user i would like to find a “getting started” guide within the documentation which introduces me to the general SCBv2 Concepts and explains

• how to install the SCBv2
• start a simple security scan