├── mlc_config.json ├── red └── README.md ├── black └── README.md ├── brown └── README.md ├── purple └── README.md ├── .github └── workflows │ ├── check-spell.yml │ ├── check-md-links.yml │ ├── release-major.yml │ ├── release-minor.yml │ └── release-patch.yml ├── activity-template.md ├── orange ├── regular-security-training-for-everyone.md ├── backup-before-deployment.md ├── same-artifact-for-environments.md ├── creation-of-evil-user-stories.md ├── regular-security-training-of-security-champions.md ├── shared-security-services.md ├── simple-visualization-of-defects.md ├── logging-of-security-events.md ├── nightly-test-libraries-with-known-vulnerabilities.md ├── team-has-a-security-champion.md ├── README.md ├── test-client-side-components-with-known-vulnerabilities.md └── follow-security-by-design-principles.md ├── .cspell.json ├── yellow ├── security-consulting-on-request.md ├── continuous-integration.md ├── README.md ├── security-code-review.md ├── simple-mob-hacking.md ├── false-positive-treatment.md ├── test-components-regarding-known-vulnerabilities.md ├── definition-of-quality-gates.md └── unit-tests-for-security-features.md ├── white ├── review-security-belt-activities.md ├── do-not-start-alone.md ├── continuously-improve-your-security-belt-rank.md ├── README.md ├── get-to-know-your-security-policies.md ├── think-about-where-the-journey-is-going.md └── onboard-management-in-security.md ├── blue ├── README.md ├── load-tests.md ├── api-fuzzing.md ├── conduction-of-threat-modeling.md ├── testing-for-bypassing-authentication-schema.md ├── get-to-know-your-design-flaws.md ├── logging-concept.md ├── code-review.md ├── dynamic-scan-for-security-vulnerabilities.md └── regular-advanced-mob-hacking.md ├── CONTRIBUTING.md ├── green ├── prevent-secrets-in-source-code.md ├── integration-of-vulnerability-issues-into-the-development-process.md ├── ensure-only-using-components-which-are-under-active-development.md ├── test-for-default-credentials.md ├── test-container-images-regarding-known-vulnerabilities.md ├── README.md ├── test-security-configuration-of-cloud-environments.md ├── environment-dependent-configuration-parameters.md ├── static-analysis-for-all-self-written-components.md ├── nightly-dependency-version-upgrade.md ├── test-security-configuration-of-infrastructure.md └── treatment-of-vulnerabilities-with-severity-high-or-higher.md ├── CODE_OF_CONDUCT.md ├── README.md └── LICENSE /mlc_config.json: -------------------------------------------------------------------------------- 1 | { 2 | "aliveStatusCodes": [200, 206, 403] 3 | } 4 | -------------------------------------------------------------------------------- /red/README.md: -------------------------------------------------------------------------------- 1 | # [](#) Red Belt [work in progress] 2 | -------------------------------------------------------------------------------- /black/README.md: -------------------------------------------------------------------------------- 1 | # [](#) Black Belt [work in progress] 2 | -------------------------------------------------------------------------------- /brown/README.md: -------------------------------------------------------------------------------- 1 | # [](#) Brown Belt [work in progress] 2 | -------------------------------------------------------------------------------- /purple/README.md: -------------------------------------------------------------------------------- 1 | # [](#) Purple Belt [work in progress] 2 | -------------------------------------------------------------------------------- /.github/workflows/check-spell.yml: -------------------------------------------------------------------------------- 1 | name: Spell check 2 | on: [push, pull_request] 3 | jobs: 4 | check: 5 | runs-on: ubuntu-latest 6 | steps: 7 | - uses: actions/checkout@v2 8 | - uses: actions/setup-node@v2 9 | with: 10 | node-version: '20' 11 | - run: npm install -g cspell 12 | - run: cspell "**/*.md" 13 | -------------------------------------------------------------------------------- /activity-template.md: -------------------------------------------------------------------------------- 1 | # TODO 2 | 3 | ## Activities 4 | 5 | - TODO 6 | 7 | ## Benefits 8 | 9 | - TODO 10 | 11 | ## Assessment 12 | 13 | - TODO 14 | 15 | ## Examples 16 | 17 | - TODO 18 | 19 | ## Related Activities 20 | 21 | - TODO 22 | 23 | ## Further Readings 24 | 25 | - TODO 26 | 27 |

Send Feedback

28 | -------------------------------------------------------------------------------- /.github/workflows/check-md-links.yml: -------------------------------------------------------------------------------- 1 | name: Check Markdown Links 2 | on: 3 | push: 4 | pull_request: 5 | schedule: 6 | - cron: '0 7 * * 1' 7 | jobs: 8 | check: 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: actions/checkout@v2 12 | - uses: gaurav-nelson/github-action-markdown-link-check@v1 13 | with: 14 | use-quiet-mode: 'yes' 15 | use-verbose-mode: 'yes' 16 | config-file: 'mlc_config.json' 17 | -------------------------------------------------------------------------------- /orange/regular-security-training-for-everyone.md: -------------------------------------------------------------------------------- 1 | # Regular Security Training for Everyone 2 | 3 | ## Activities 4 | 5 | - Attend security *Software Development Life Cycle* (SDLC) trainings with the team on a regular basis. 6 | 7 | ## Benefits 8 | 9 | - Improve security knowledge within the team. 10 | - Keeping up with evolving security threats, vulnerabilities, and best practices. 11 | 12 | ## Assessment 13 | 14 | - Each team member talks about their key takeaways of the security SDLC training. 15 | 16 |

Send Feedback

17 | -------------------------------------------------------------------------------- /orange/backup-before-deployment.md: -------------------------------------------------------------------------------- 1 | # Backup Before Deployment 2 | 3 | Changes to the application might corrupt its data. 4 | 5 | ## Activities 6 | 7 | - Perform preparations to restore the data to a pre-deployment state. 8 | 9 | ## Benefits 10 | 11 | - Prevent corruption of the database during deployment, which could lead to downtime or loss of customer data. 12 | 13 | ## Assessment 14 | 15 | - Show preparations of your restore procedure for the last release. 16 | - Execute your restore procedure in a test environment. 17 | 18 |

Send Feedback

19 | -------------------------------------------------------------------------------- /.cspell.json: -------------------------------------------------------------------------------- 1 | { 2 | "version": "0.1", 3 | "language": "en", 4 | "words": [ 5 | "OWASP", 6 | "SDLC", 7 | "Unparser", 8 | "SAMM", 9 | "Grafana", 10 | "Heise", 11 | "Spotbugs", 12 | "SonarQube", 13 | "CogniCrypt", 14 | "ERDF", 15 | "EFRE", 16 | "DVWA", 17 | "Modellgetriebene", 18 | "Entwicklung", 19 | "HITB", 20 | "Ingolf", 21 | "Organisational", 22 | "Dependabot", 23 | "Gitrob", 24 | "nmap", 25 | "Anchore", 26 | "Grundschutz", 27 | "Bausteine", 28 | "Threagile", 29 | "ffuf", 30 | "Gobuster", 31 | "socio" 32 | ] 33 | } 34 | -------------------------------------------------------------------------------- /yellow/security-consulting-on-request.md: -------------------------------------------------------------------------------- 1 | # Security Consulting on Request 2 | 3 | ## Activities 4 | 5 | - Actively consult the Security Champion Guild if your own knowledge is insufficient to solve security problems. 6 | 7 | ## Benefits 8 | 9 | - Decisions that compromise software security can be avoided. 10 | 11 | ## Assessment 12 | 13 | - Show cases where you were able to solve security issues without help. 14 | - Show cases where you could only solve security issues with help. 15 | - Show cases in which you have treated false positives. 16 | 17 |

Send Feedback

18 | -------------------------------------------------------------------------------- /yellow/continuous-integration.md: -------------------------------------------------------------------------------- 1 | # Continuous Integration 2 | 3 | ## Activities 4 | 5 | - Use continuous automated building and testing of the software. 6 | 7 | ## Benefits 8 | 9 | - Quality is visible to everyone 10 | - There is a single instance deciding whether the code meets its quality (single ground of truth). 11 | - Deterministic and reproducible builds 12 | 13 | ## Assessment 14 | 15 | - Show your build pipeline and an exemplary job (build + test). 16 | - Show that every team member has access. 17 | - Show that failed jobs are fixed. 18 | 19 | ## Further Readings 20 | 21 | - Literature: [Continuous Integration](https://martinfowler.com/articles/continuousIntegration.html) 22 | 23 |

Send Feedback

24 | -------------------------------------------------------------------------------- /white/review-security-belt-activities.md: -------------------------------------------------------------------------------- 1 | # Review Security Belt Activities 2 | 3 | ## Activities 4 | 5 | - After implementing a security belt activity, approach the Security Champion Guild for a review. 6 | - Use the early feedback of the single activity before the assessment of the whole belt. 7 | 8 | ## Benefits 9 | 10 | - Eradicate misunderstandings of security belt activities early. 11 | - Early feedback before the belt assessment. 12 | - The quality of the implementation is increased. 13 | - Successes can be celebrated intermediately. 14 | 15 | ## Assessment 16 | 17 | - The white belt shall create the commitment to work on the Security Belts. Therefore, it does not require any assessment. 18 | 19 |

Send Feedback

20 | -------------------------------------------------------------------------------- /white/do-not-start-alone.md: -------------------------------------------------------------------------------- 1 | # Don't Start Alone 2 | 3 | ## Activities 4 | 5 | - When implementing a security belt activity, approach a peer from the Security Champion Guild to get you started. 6 | - Schedule a meeting to ensure you both work on nothing else. 7 | 8 | ## Benefits 9 | 10 | - Knowledge how to implement security belt activities is spread, so everyone benefits of prior knowledge. 11 | - Starting to implement security belt activities with guidance is easier. 12 | - The team is improving its software security while avoiding previously made mistakes. 13 | 14 | ## Assessment 15 | 16 | - The white belt shall create the commitment to work on the Security Belts. Therefore, it does not require any assessment. 17 | 18 |

Send Feedback

19 | -------------------------------------------------------------------------------- /orange/same-artifact-for-environments.md: -------------------------------------------------------------------------------- 1 | # Same Artifact for Environments 2 | 3 | ## Activities 4 | 5 | - Build your artifacts only once. 6 | - Use the same artifact for testing as well as for production purposes. 7 | - This ensures your artifact in production is the one you tested. 8 | - Do not use environment names to configure your artifact. 9 | 10 | ## Benefits 11 | 12 | - The tested artifact is the one which is deployed. 13 | - No environment specific changes are required right before production deployment. 14 | - Therefore, bugs introduced by these changes are prevented. 15 | 16 | ## Assessment 17 | 18 | - Show the hash sum of your artifact after: 19 | - build 20 | - deploy in a test environment 21 | - deploy in the production environment 22 | - Show all configuration parameters of your artifact. 23 | 24 |

Send Feedback

25 | -------------------------------------------------------------------------------- /orange/creation-of-evil-user-stories.md: -------------------------------------------------------------------------------- 1 | # Creation of Evil User Stories 2 | 3 | ## Activities 4 | 5 | - Create evil user stories to complement user stories from a security perspective. 6 | - Use a template like for normal user stores: 7 | ``` 8 | As a , I can , so that . 9 | ``` 10 | - Create an *evil* user story by describing an attack scenario on an application. Keep in mind to cover abuse as well as misuse. 11 | 12 | ## Benefits 13 | 14 | - The team also deals with security requirements. 15 | - Relevant security considerations are performed. 16 | - Security flaws can be discovered or prevented early. 17 | 18 | ## Assessment 19 | 20 | - Show *n* user stories and their evil user story counterparts. 21 | - Show how the team considers the evil user stories during design and implementation. 22 | 23 |

Send Feedback

24 | -------------------------------------------------------------------------------- /orange/regular-security-training-of-security-champions.md: -------------------------------------------------------------------------------- 1 | # Regular Security Training of Security Champions 2 | 3 | *Security is a journey.* 4 | 5 | ## Activities 6 | 7 | - Let the Security Champion attend security trainings on a regular (e.g., yearly) basis. 8 | - The key takeaways from the training shall be shared with the team and other Security Champions. 9 | 10 | ## Benefits 11 | 12 | - Improve security knowledge within the team. 13 | - Keeping up with evolving security threats, vulnerabilities, and best practices. 14 | 15 | ## Assessment 16 | 17 | - The Security Champion talks about the key takeaways of the security focused training. 18 | 19 | ## Examples 20 | 21 | Some example conferences that offer trainings: 22 | - OWASP Global AppSec 23 | - Heise DevSec 24 | - Troopers 25 | - DevSecCon 26 | - RuhrSec 27 | - IT-Defense 28 | - BlackHat 29 | - SecAppDev 30 | - HITB 31 | 32 |

Send Feedback

33 | -------------------------------------------------------------------------------- /orange/shared-security-services.md: -------------------------------------------------------------------------------- 1 | # Shared Security Services 2 | 3 | ## Activities 4 | 5 | - Do not reinvent the wheel. 6 | - Prefer shared security services and components over implementing security controls yourself. 7 | - Challenge that these services perform well and secure. 8 | - Furthermore, make deficiencies transparent. 9 | 10 | ## Benefits 11 | 12 | - Widely used software is less risky to use as problems are more likely to be discovered. 13 | - Even minor mistakes in your own security controls could lead to serious security issues. By using shared services, you prevent this risk. 14 | 15 | ## Assessment 16 | 17 | - Show the shared security services in your architecture. 18 | - What do you use for: 19 | - Crypto 20 | - Parser (like file upload validation) 21 | - Unparser (like HTML generation) 22 | - Authentication, authorization 23 | - Session management 24 | 25 |

Send Feedback

26 | -------------------------------------------------------------------------------- /.github/workflows/release-major.yml: -------------------------------------------------------------------------------- 1 | name: Release Major 2 | on: [workflow_dispatch] 3 | jobs: 4 | release: 5 | runs-on: ubuntu-latest 6 | steps: 7 | - uses: actions/checkout@v2 8 | - id: changelog 9 | uses: metcalfc/changelog-generator@v1.0.0 10 | with: 11 | myToken: ${{ secrets.GITHUB_TOKEN }} 12 | - id: previous_version 13 | uses: "WyriHaximus/github-action-get-previous-tag@v1" 14 | with: 15 | fallback: 1.0.0 16 | - id: increment_version 17 | uses: "WyriHaximus/github-action-next-semvers@v1" 18 | with: 19 | version: ${{ steps.previous_version.outputs.tag }} 20 | - uses: actions/create-release@latest 21 | env: 22 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 23 | with: 24 | tag_name: ${{ steps.increment_version.outputs.v_major }} 25 | release_name: ${{ steps.increment_version.outputs.v_major }} 26 | body: ${{ steps.changelog.outputs.changelog }} 27 | -------------------------------------------------------------------------------- /.github/workflows/release-minor.yml: -------------------------------------------------------------------------------- 1 | name: Release Minor 2 | on: [workflow_dispatch] 3 | jobs: 4 | release: 5 | runs-on: ubuntu-latest 6 | steps: 7 | - uses: actions/checkout@v2 8 | - id: changelog 9 | uses: metcalfc/changelog-generator@v1.0.0 10 | with: 11 | myToken: ${{ secrets.GITHUB_TOKEN }} 12 | - id: previous_version 13 | uses: "WyriHaximus/github-action-get-previous-tag@v1" 14 | with: 15 | fallback: 1.0.0 16 | - id: increment_version 17 | uses: "WyriHaximus/github-action-next-semvers@v1" 18 | with: 19 | version: ${{ steps.previous_version.outputs.tag }} 20 | - uses: actions/create-release@latest 21 | env: 22 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 23 | with: 24 | tag_name: ${{ steps.increment_version.outputs.v_minor }} 25 | release_name: ${{ steps.increment_version.outputs.v_minor }} 26 | body: ${{ steps.changelog.outputs.changelog }} 27 | -------------------------------------------------------------------------------- /.github/workflows/release-patch.yml: -------------------------------------------------------------------------------- 1 | name: Release Patch 2 | on: [workflow_dispatch] 3 | jobs: 4 | release: 5 | runs-on: ubuntu-latest 6 | steps: 7 | - uses: actions/checkout@v2 8 | - id: changelog 9 | uses: metcalfc/changelog-generator@v1.0.0 10 | with: 11 | myToken: ${{ secrets.GITHUB_TOKEN }} 12 | - id: previous_version 13 | uses: "WyriHaximus/github-action-get-previous-tag@v1" 14 | with: 15 | fallback: 1.0.0 16 | - id: increment_version 17 | uses: "WyriHaximus/github-action-next-semvers@v1" 18 | with: 19 | version: ${{ steps.previous_version.outputs.tag }} 20 | - uses: actions/create-release@latest 21 | env: 22 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 23 | with: 24 | tag_name: ${{ steps.increment_version.outputs.v_patch }} 25 | release_name: ${{ steps.increment_version.outputs.v_patch }} 26 | body: ${{ steps.changelog.outputs.changelog }} 27 | -------------------------------------------------------------------------------- /orange/simple-visualization-of-defects.md: -------------------------------------------------------------------------------- 1 | # Simple Visualization of Defects 2 | 3 | ## Activities 4 | 5 | - Collect defects (e.g., vulnerabilities, bugs) of software components the team is responsible. 6 | - Make these defects visible to all team members. 7 | - The collection should be up to date and easy to understand for every team member. 8 | 9 | *Note*: Providing access to all team members is much more important than collecting all defects in one place. 10 | 11 | ## Benefits 12 | 13 | - The quality of all software components is visible. 14 | - The team is able to prioritize defects. 15 | 16 | ## Assessment 17 | 18 | - Show all your defects. 19 | - Show that every team member has access. 20 | 21 | ## Further Readings 22 | 23 | - Tool: [OWASP Defect Dojo](https://owasp.org/www-project-defectdojo/) 24 | - Tool: [Jenkins Next Generation Warnings plugin](https://plugins.jenkins.io/warnings-ng/) 25 | - Tool: [Grafana](https://grafana.com/) 26 | 27 |

Send Feedback

28 | -------------------------------------------------------------------------------- /yellow/README.md: -------------------------------------------------------------------------------- 1 | # [](#) Yellow Belt 2 | 3 | The yellow belt introduces activities to automatically build and test the developed software and, as such, gives the team continuous high-level feedback on its current state. It is recommended that every team achieves this belt. 4 | 5 | - [Continuous Integration](continuous-integration.md) 6 | - [Security Code Review](security-code-review.md) 7 | - [Security Consulting on Request](security-consulting-on-request.md) 8 | - [Test Components Regarding Known Vulnerabilities](test-components-regarding-known-vulnerabilities.md) 9 | - [Definition of Quality Gates](definition-of-quality-gates.md) 10 | - [False Positive Treatment](false-positive-treatment.md) 11 | - [Unit Tests for Security Features](unit-tests-for-security-features.md) 12 | - [Simple Mob Hacking](simple-mob-hacking.md) 13 | 14 |

Send Feedback

15 | -------------------------------------------------------------------------------- /blue/README.md: -------------------------------------------------------------------------------- 1 | # [](#) Blue Belt 2 | 3 | The blue belt introduces activities to gain a deeper understanding of the behavior of your developed software under attack. 4 | You learn advanced methods and tools for identifying and exploiting vulnerabilities regarding design and implementation flaws. 5 | 6 | - [Code Review](code-review.md) 7 | - [Conduction of Threat Modeling](conduction-of-threat-modeling.md) 8 | - [Get to Know Your Design Flaws](get-to-know-your-design-flaws.md) 9 | - [Dynamic Scan for Security Vulnerabilities](dynamic-scan-for-security-vulnerabilities.md) 10 | - [API Fuzzing](api-fuzzing.md) 11 | - [Regular Advanced Mob Hacking](regular-advanced-mob-hacking.md) 12 | - [Load Tests](load-tests.md) 13 | - [Logging Concept](logging-concept.md) 14 | - [Testing for Bypassing Authentication Schema](testing-for-bypassing-authentication-schema.md) 15 | 16 |

Send Feedback

17 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | ## Contributing Feedback 4 | 5 | In order to continuously improve the Security Belts model, we appreciate any kind of feedback. You can: 6 | - Fill out our surveys for the methodology, belts and belt activities. 7 | - Create a [new issue](https://github.com/AppSecure-nrw/security-belts/issues/new/choose) expressing your concerns and suggestions. 8 | - Email us at security-belts@iem.fraunhofer.de. 9 | 10 | ## Contributing Content 11 | 12 | - Create a new Pull Request based on the **master** branch. 13 | - Please let us know if you plan to work on an open issue (e.g., make a comment in the issue). This way, we can avoid redundant work. 14 | - All your changes are under [CC-BY-SA-4.0 License](LICENSE). 15 | 16 | ## Code of Conduct 17 | 18 | This project and everyone participating in it is governed by our [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. 19 | -------------------------------------------------------------------------------- /yellow/security-code-review.md: -------------------------------------------------------------------------------- 1 | # Security Code Review 2 | 3 | ## Activities 4 | 5 | - Perform code reviews of security-related software and infrastructure with the Security Champion Guild. 6 | 7 | The following areas of code tend to have a high-risk of containing security vulnerabilities: 8 | - Crypto implementations / usage 9 | - Parser, unparser 10 | - System configuration 11 | - Authentication, authorization 12 | - Session management 13 | - Request throttling 14 | - :unicorn: (self-developed code, only used in that one software) 15 | 16 | ## Benefits 17 | 18 | - New vulnerabilities may be found before reaching production. 19 | - Old vulnerabilities are found and fixed. 20 | 21 | ## Assessment 22 | 23 | - Present the performed reviews (including participants, findings, consequences) and assess whether it is reasonable. 24 | 25 | ## Further Readings 26 | 27 | - Literature: [CWE Top 25 Most Dangerous Software Weaknesses](https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html) 28 | 29 |

Send Feedback

30 | -------------------------------------------------------------------------------- /white/continuously-improve-your-security-belt-rank.md: -------------------------------------------------------------------------------- 1 | # Continuously Improve your Security Belt Rank 2 | 3 | Security is like a big pizza. You cannot eat it as a whole, but you can slice it and continuously eat small slices. Security belt activities make good slices because they are of reasonable size and have a defined output. 4 | 5 | ## Activities 6 | 7 | - Ensure that the Product Owner continuously prioritizes the security belt activities for the next belt highly within the product backlog. 8 | - Celebrate all your implemented security belt activities. 9 | 10 | ## Benefits 11 | 12 | - The team has time to improve its software security. 13 | - The team's initially high motivation and momentum can be used. 14 | - The Product Owner has transparency of the investment and benefit of security belts. 15 | - The team is improving its software security. 16 | 17 | ## Assessment 18 | 19 | - The white belt shall create the commitment to work on the Security Belts. Therefore, it does not require any assessment. 20 | 21 |

Send Feedback

22 | -------------------------------------------------------------------------------- /white/README.md: -------------------------------------------------------------------------------- 1 | # [](#) White Belt 2 | 3 | The white belt - with its activities - shall lay the organizational basis for the improvement of your software security. Unlike other belts, it has no assessment. Once your team and Product Owner commit to work on the Security Belts, you can claim the white belt and start working on the next Security Belt. 4 | 5 | ## Activities 6 | 7 | - [Onboard Management in Security](onboard-management-in-security.md) 8 | - [Get to Know Your Security Policies](get-to-know-your-security-policies.md) 9 | - [Think about where the journey is going](think-about-where-the-journey-is-going.md) 10 | - [Don't Start Alone](do-not-start-alone.md) 11 | - [Continuously Improve your Security Belt Rank](continuously-improve-your-security-belt-rank.md) 12 | - [Review Security Belt Activities](review-security-belt-activities.md) 13 | 14 | ## Further Readings 15 | 16 | - Literature: [Culture Eats Technology for Lunch](https://www.entrepreneur.com/article/245511) -David DeWolf 17 | 18 |

Send Feedback

19 | -------------------------------------------------------------------------------- /green/prevent-secrets-in-source-code.md: -------------------------------------------------------------------------------- 1 | # Prevent Secrets in Source Code 2 | 3 | ## Activities 4 | 5 | - Avoid hard-coded secrets (e.g., credentials) in application and infrastructure source code. 6 | - Automate this task by using Git pre-commit hooks or similar techniques. 7 | 8 | ## Benefits 9 | 10 | - No leakage of confidential data through compromised source code. 11 | - Credentials are not located in the version control system repositories. 12 | 13 | ## Assessment 14 | 15 | - Show the usage of the tool(s). 16 | - Show the handling of the results. 17 | - Show the latest *n* findings. 18 | - Show your false positive list. 19 | 20 | ## Related Activities 21 | 22 | - [](#) [Environment-Dependent Configuration Parameters](../green/environment-dependent-configuration-parameters.md) 23 | 24 | ## Further Readings 25 | 26 | - Tool: [truffleHog](https://github.com/dxa4481/truffleHog) 27 | - Tool: [Gitrob](https://github.com/michenriksen/gitrob) 28 | - Tool: [SonarQube](https://www.sonarqube.org/) 29 | 30 |

Send Feedback

31 | -------------------------------------------------------------------------------- /green/integration-of-vulnerability-issues-into-the-development-process.md: -------------------------------------------------------------------------------- 1 | # Integration of Vulnerability Issues into the Development Process 2 | 3 | ## Activities 4 | 5 | - Treat all your identified vulnerabilities the same way as your other user stories. 6 | - Therefore, add them as issues to the same board, preferably using an automated process. 7 | 8 | ## Benefits 9 | 10 | - Creates visibility of the current state of issues and their treatment to the whole team. 11 | - Enables prioritization of security-relevant issues for the Product Owner. 12 | 13 | 14 | ## Assessment 15 | 16 | - Verify that issues exist for all relevant vulnerabilities. 17 | - Verify that vulnerabilities from all sources are included. 18 | 19 | ## Related Activities 20 | 21 | - [](#) [Treatment of Vulnerabilities with Severity High or Higher](../green/treatment-of-vulnerabilities-with-severity-high-or-higher.md) 22 | 23 | ## Further Readings 24 | 25 | - Tool: [OWASP DefectDojo](https://github.com/DefectDojo/django-DefectDojo) 26 | 27 |

Send Feedback

28 | -------------------------------------------------------------------------------- /orange/logging-of-security-events.md: -------------------------------------------------------------------------------- 1 | # Logging of Security Events 2 | 3 | ## Activities 4 | 5 | - Implement logging of security relevant events. 6 | 7 | The following events tend to be security relevant: 8 | - successful/failed login/logout 9 | - creation, change, and deletion of users 10 | - errors during input validation and output creation 11 | - exceptions and errors with security in their name 12 | - transactions of value (e.g., financial transactions, costly operations) 13 | - :unicorn: (special things of your application) 14 | 15 | ## Benefits 16 | 17 | - Security incident analysis takes significantly less time with proper security events, such that an attack can be stopped before the attacker reaches his goal. 18 | 19 | ## Assessment 20 | 21 | - Show which events are logged. 22 | - Show a test for one event logging. 23 | 24 | ## Further Readings 25 | 26 | - Literature: [Logging CheatSheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) 27 | - Literature: [How attacker can exploit logger](https://owasp.org/www-community/attacks/Log_Injection) 28 | - Tool: [OWASP AppSensor](http://www.appsensor.org) 29 | 30 |

Send Feedback

31 | -------------------------------------------------------------------------------- /orange/nightly-test-libraries-with-known-vulnerabilities.md: -------------------------------------------------------------------------------- 1 | # Nightly Test Libraries With Known Vulnerabilities 2 | 3 | ## Activities 4 | 5 | - Perform nightly tests for known vulnerabilities in all libraries used by your software. 6 | 7 | ## Benefits 8 | 9 | - Known vulnerabilities in used libraries are found and do not pile up without notice. 10 | - The nightly schedule of the tests do not distract the team and allows focused work. 11 | 12 | ## Assessment 13 | 14 | - Show your nightly pipeline and an exemplary job. 15 | - Show that failed jobs are fixed. 16 | 17 | ## Related Activities 18 | 19 | - [](#) [Test Components Regarding Known Vulnerabilities](../yellow/test-components-regarding-known-vulnerabilities.md) 20 | 21 | ## Further Readings 22 | 23 | - Tool: [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/) 24 | - Literature: [OWASP Top Ten: 9. Using Components with Known Vulnerabilities](https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities) 25 | 26 |

Send Feedback

27 | -------------------------------------------------------------------------------- /green/ensure-only-using-components-which-are-under-active-development.md: -------------------------------------------------------------------------------- 1 | # Ensure Only Using Components Which Are Under Active Development 2 | 3 | ## Activities 4 | 5 | - Ensure that you only use software components (e.g., libraries, applications) which are under active development. 6 | - This also includes migrating software **before** it reaches end of life / support. 7 | 8 | ## Benefits 9 | 10 | - All software components are up-to-date and receive security patches for discovered vulnerabilities. 11 | - Newer technologies help to minimize your attack surface (e.g., use latest TLS version) 12 | - Simplifies effective implementation of other belt activities. 13 | 14 | ## Assessment 15 | 16 | - Show the established process or tooling that allows to regularly check the lifecycle of all used software components. 17 | - Show the handling of the results. 18 | - Show the latest *n* findings. 19 | 20 | ## Related Activities 21 | 22 | - [](#) [Nightly Dependency Version Upgrade](../green/nightly-dependency-version-upgrade.md) 23 | 24 |

Send Feedback

25 | -------------------------------------------------------------------------------- /blue/load-tests.md: -------------------------------------------------------------------------------- 1 | # Load Tests 2 | 3 | ## Activities 4 | 5 | - Define or identify your specific performance requirements. 6 | - Perform corresponding load tests against your application and infrastructure components. 7 | - If possible, use tools to automate this task as much as possible. 8 | 9 | ## Benefits 10 | 11 | - Know the limits of your application and infrastructure components. 12 | - Ability to scale appropriately for expected load cases. 13 | - Improve availability and resilience of your application. 14 | 15 | ## Assessment 16 | 17 | - Show the usage of the tool(s). 18 | - Show the handling of the results. 19 | - Show the latest *n* findings. 20 | - Show your false positive list. 21 | 22 | ## Related Activities 23 | 24 | - [](#) [Follow Security by Design Principles](../orange/follow-security-by-design-principles.md) 25 | 26 | ## Further Readings 27 | 28 | - Tool: [Gatling](https://gatling.io/) 29 | - Tool: [Apache JMeter](https://jmeter.apache.org/) 30 | - Tool: [Burp](https://portswigger.net/burp) 31 | - Tool: [ffuf](https://github.com/ffuf/ffuf) 32 | 33 |

Send Feedback

34 | -------------------------------------------------------------------------------- /white/get-to-know-your-security-policies.md: -------------------------------------------------------------------------------- 1 | # Get to Know Your Security Policies 2 | 3 | ## Activities 4 | 5 | - Identify the security policies of your organization and adhere to them. 6 | - If there are no security policies, this must be made transparent to the management. 7 | - Be aware, security policies alone do not ensure secure software, they can only serve as a framework. 8 | - Share with the Security Champion Guild how you perform the required activities from the policies, so others can benefit from your experience. In addition, provide feedback to the policy owner. 9 | - Whenever you find yourself not adhering to the policies, communicate this to the person responsible for judging "risks vs. revenue" on your product (e.g., your Product Owner, manager), so they are aware of being out of policy. 10 | 11 | ## Benefits 12 | 13 | - Building and operating software securely is hard; utilizing standards (as described in the security policies) makes it at least a bit easier. 14 | - Basic security risks, which are covered by security policies, are handled. 15 | 16 | ## Assessment 17 | 18 | - The white belt shall create the commitment to work on the Security Belts. Therefore, it does not require any assessment. 19 | 20 |

Send Feedback

21 | -------------------------------------------------------------------------------- /orange/team-has-a-security-champion.md: -------------------------------------------------------------------------------- 1 | # Team has a Security Champion 2 | 3 | ## Activities 4 | 5 | - Find and train a [Security Champion](https://github.com/AppSecure-nrw/security-belts/wiki/Security-Champion) from within the team. 6 | 7 | *Note*: The Security Champion should be a volunteer interested in software security. Just forcing someone to take the role is worse than having no Security Champion. 8 | 9 | ## Benefits 10 | 11 | - The Security Champion brings security knowledge to the team so that the team can make informed security decisions and take responsibility for security. 12 | - Central security experts can focus on other tasks. 13 | 14 | ## Assessment 15 | 16 | - Show that the Security Champion has completed a security training. 17 | - Show the improvements and activities made by the Security Champion, e.g., training the team and executing belt activities. 18 | 19 | ## Further Readings 20 | 21 | - Literature: "Finding Security Champions in Blends of Organisational Culture" by Ingolf Becker et al, 2017 22 | - Literature: "Selecting Security Champions" by Trevor Gabriel et al., 2011 23 | - Training: [Fraunhofer IEM - Security Champion Training](https://www.iem.fraunhofer.de/de/academy/schulungsangebot/security-champion-training.html) 24 | 25 |

Send Feedback

26 | -------------------------------------------------------------------------------- /green/test-for-default-credentials.md: -------------------------------------------------------------------------------- 1 | # Test for Default Credentials 2 | 3 | ## Activities 4 | 5 | - Test for default credentials of users within all used third party components (e.g., application server, database) of your product that are reachable over network. 6 | 7 | ## Benefits 8 | 9 | - Default credentials are a very easy way to access your third party components. By disabling those, your application becomes much more secure. 10 | - Default users have often privileged access. 11 | 12 | ## Assessment 13 | 14 | - Show the tests and usage of the tool(s). 15 | - Show the handling of the results. 16 | - Show the latest *n* findings. 17 | 18 | ## Related Activities 19 | 20 | - [](#) [Continuous Integration](../yellow/continuous-integration.md) 21 | 22 | ## Further Readings 23 | 24 | - Tool: [Hydra](https://github.com/vanhauser-thc/thc-hydra) 25 | - Tool: [nmap script for http default accounts](https://nmap.org/nsedoc/scripts/http-default-accounts.html) 26 | - Literature: [OWASP Testing Guide 4.4.2](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials.html) 27 | 28 |

Send Feedback

29 | -------------------------------------------------------------------------------- /yellow/simple-mob-hacking.md: -------------------------------------------------------------------------------- 1 | # Simple Mob Hacking 2 | 3 | ## Activities 4 | 5 | - Participate with your whole team in a simple mob hacking session organized by the Security Champion Guild. 6 | - In the session, the guild presents a vulnerable application and together you look at possible exploits. 7 | 8 | Guidelines for your simple mob hacking session: 9 | - Just like in mob programming, there is one driver and several navigators. 10 | - All exploits happen via the user interface. 11 | - No need for security/hacking tools. 12 | - No need for deep technical or security knowledge. 13 | - Use an insecure training app, e.g., [DVWA](https://github.com/digininja/DVWA) 14 | - Encourage active participation, e.g., use small groups. 15 | - Allow enough time for everyone to run at least one exploit. 16 | 17 | ## Benefits 18 | 19 | - The team gets an idea of how exploits can look like and how easy applications can be attacked. 20 | - The team understands functional correct working software can be highly insecure and easy to exploit. 21 | 22 | ## Assessment 23 | 24 | - Report on the most surprising experiences from a session. 25 | - Report on your lessons learned. 26 | 27 | ## Further Readings 28 | 29 | - Tool: [DVWA](https://github.com/digininja/DVWA) 30 | - Tool: [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/) 31 | 32 |

Send Feedback

33 | -------------------------------------------------------------------------------- /blue/api-fuzzing.md: -------------------------------------------------------------------------------- 1 | # API Fuzzing 2 | 3 | ## Activities 4 | 5 | - Perform API fuzzing regarding parameter names, malicious values, and unknown endpoints. 6 | 7 | ## Benefits 8 | 9 | - Typical low hanging fruit vulnerabilities can be found and fixed. 10 | - The developed software is not vulnerable to well established attacks. 11 | 12 | ## Assessment 13 | 14 | - Show the usage of the tool(s). 15 | - Show the handling of the results. 16 | - Show the latest *n* findings. 17 | - Show your false positive list. 18 | 19 | ## Related Activities 20 | 21 | - [](#) [Treatment of Vulnerabilities With Severity High or Higher](../green/treatment-of-vulnerabilities-with-severity-high-or-higher.md) 22 | - [](#) [Dynamic Scan for Security Vulnerabilities](../blue/dynamic-scan-for-security-vulnerabilities.md) 23 | 24 | ## Further Readings 25 | 26 | - Literature: [Fuzzing](https://owasp.org/www-community/Fuzzing) 27 | - Tool: [Burp](https://portswigger.net/burp) 28 | - Tool: [OWASP ZAP](https://www.zaproxy.org/) 29 | - Tool: [ffuf](https://github.com/ffuf/ffuf) 30 | - Specification: [OpenAPI](https://www.openapis.org/) 31 | 32 |

Send Feedback

33 | -------------------------------------------------------------------------------- /green/test-container-images-regarding-known-vulnerabilities.md: -------------------------------------------------------------------------------- 1 | # Test Container Images Regarding Known Vulnerabilities 2 | 3 | ## Activities 4 | 5 | - Perform tests for known vulnerabilities in all container images used by your software. 6 | - Use tools to automate your tests. 7 | 8 | ## Benefits 9 | 10 | - Known vulnerabilities in used containers are found and can be fixed. 11 | - The system is not vulnerable to well known attacks in middle-ware it relies on. 12 | 13 | ## Assessment 14 | 15 | - Show the tests and usage of the tool(s). 16 | - Show the handling of the results. 17 | - Show the latest *n* findings. 18 | - Show your false positive list. 19 | 20 | ## Related Activities 21 | 22 | - [](#) [Continuous Integration](../yellow/continuous-integration.md) 23 | - [](#) [Definition of Quality Gates](../yellow/definition-of-quality-gates.md) 24 | 25 | ## Further Readings 26 | 27 | - Tool: [JFrog Xray](https://jfrog.com/xray/) 28 | - Tool: [Anchore](https://anchore.com/) 29 | - Tool: [Clair](https://github.com/quay/clair/releases) 30 | 31 |

Send Feedback

32 | -------------------------------------------------------------------------------- /blue/conduction-of-threat-modeling.md: -------------------------------------------------------------------------------- 1 | # Conduction of Threat Modeling 2 | 3 | ## Activities 4 | 5 | - Identify threats by performing threat modeling (e.g., apply [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security))) for your product including all internal, external, and third-party components (e.g., services, databases) and interactions between them. 6 | - Keep the model up to date. 7 | - Identify and address the resulting risks. 8 | - Perform regularly reviews of the security mechanisms of your architecture. 9 | 10 | ## Benefits 11 | 12 | - Early (i.e., during design phase) detection & mitigation of possible threats. 13 | - Relevant security considerations are performed. 14 | - Common understanding of the product architecture. 15 | 16 | ## Assessment 17 | 18 | - Show your threat model(s). 19 | - Show the handling of the results. 20 | 21 | ## Related Activities 22 | 23 | - [](#) [Get to Know Your Security Policies](../white/get-to-know-your-security-policies.md) 24 | 25 | ## Further Readings 26 | 27 | - Literature: [STRIDE Threat Modeling](https://en.wikipedia.org/wiki/STRIDE_(security)) 28 | - Tool: [MS Threat Modeling](https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling) 29 | - Tool: [Threagile](https://threagile.io/) 30 | 31 |

Send Feedback

32 | -------------------------------------------------------------------------------- /white/think-about-where-the-journey-is-going.md: -------------------------------------------------------------------------------- 1 | # Think about where the journey is going 2 | 3 | Achieving the highest Security Belt might not make economic sense and may therefore not be necessary. 4 | 5 | ## Activities 6 | 7 | - Estimate which Security Belt might be sufficient for the business criticality of your software. Your estimate might be just a first guess. To estimate, take a look at: 8 | - which kind of data is processed by your software. 9 | - how important your software is for your core business. 10 | - possible attack scenarios and how they could harm your software and data. 11 | - your compliance and regulatory requirements. 12 | - Or, in case you have a central security department that requires you to adhere to the central risk management, consider one of the following: 13 | - start an agile transformation. 14 | - adhere to their risk judgement. 15 | - leave the company. 16 | - Commit on your estimation with your Product Owner. 17 | - Challenge your estimation after each achieved Security Belt. Since you should have a better understanding of security, your estimation should become more profound. 18 | 19 | ## Benefits 20 | 21 | - The team is motivated by a given goal for their journey. 22 | - It is easier for the team to track their progress with a finish line ahead. 23 | 24 | ## Assessment 25 | 26 | - The white belt shall create the commitment to work on the Security Belts. Therefore, it does not require any assessment. 27 | 28 |

Send Feedback

29 | -------------------------------------------------------------------------------- /orange/README.md: -------------------------------------------------------------------------------- 1 | # [](#) Orange Belt 2 | 3 | The orange belt introduces the Security Champion as a security expert in each team who also connects the team with the Security Champion Guild. Once your team successfully achieved the orange belt, security topics and skills are in the mind of every developer and are visible within the team and especially for the Product Owner. 4 | 5 | - [Team has a Security Champion](team-has-a-security-champion.md) 6 | - [Regular Security Training of Security Champions](regular-security-training-of-security-champions.md) 7 | - [Regular Security Training for Everyone](regular-security-training-for-everyone.md) 8 | - [Follow Security by Design Principles](follow-security-by-design-principles.md) 9 | - [Creation of Evil User Stories](creation-of-evil-user-stories.md) 10 | - [Test Client Side Components With Known Vulnerabilities](test-client-side-components-with-known-vulnerabilities.md) 11 | - [Simple Visualization of Defects](simple-visualization-of-defects.md) 12 | - [Backup Before Deployment](backup-before-deployment.md) 13 | - [Same Artifact for Environments](same-artifact-for-environments.md) 14 | - [Logging of Security Events](logging-of-security-events.md) 15 | - [Nightly Test Libraries With Known Vulnerabilities](nightly-test-libraries-with-known-vulnerabilities.md) 16 | - [Shared Security Services](shared-security-services.md) 17 | 18 |

Send Feedback

19 | -------------------------------------------------------------------------------- /yellow/false-positive-treatment.md: -------------------------------------------------------------------------------- 1 | # False Positive Treatment 2 | 3 | ## Activities 4 | 5 | - Suppress false positives so that they will not show up on the next tests again. 6 | - This will help you to see the real vulnerabilities (not hidden among many many false positives anymore). 7 | 8 | For suppressions: 9 | - Document a reasonable justification (use the locality principle: as close to the code as possible). 10 | - Note on reasonable: Determine how much information your company needs, maybe it could be interesting for assessments as well? 11 | - Review your suppressions in a team (use [help](security-consulting-on-request.md) if necessary). 12 | 13 | ## Benefits 14 | 15 | - Easier to spot real positives, as the false positives will be automatically ignored. 16 | - Higher motivation to look at the found results as same false positives findings are not checked over and over. 17 | 18 | ## Assessment 19 | 20 | - Provide your false positive list. 21 | - Provide your justifications for your false positives and explain some of them. 22 | 23 | ## Related Activities 24 | 25 | - [](#) [Security Consulting on Request](../yellow/security-consulting-on-request.md) 26 | - [](#) [Security Code Review](../yellow/security-code-review.md) 27 | 28 |

Send Feedback

29 | -------------------------------------------------------------------------------- /yellow/test-components-regarding-known-vulnerabilities.md: -------------------------------------------------------------------------------- 1 | # Test Components Regarding Known Vulnerabilities 2 | 3 | ## Activities 4 | 5 | - Perform tests for known vulnerabilities in all software components used by your software (e.g., libraries, but not containers (see related belt activity)). 6 | 7 | ## Benefits 8 | 9 | - Known vulnerabilities in used components are found and can be fixed. 10 | - The developed software is not vulnerable to well established attacks. 11 | 12 | ## Assessment 13 | 14 | - Show the tests and usage of the tool(s). 15 | - Show the handling of the results. 16 | - Show the latest *n* findings. 17 | - Show your false positive list. 18 | 19 | ## Related Activities 20 | 21 | - [](#) [Continuous Integration](../yellow/continuous-integration.md) 22 | - [](#) [Definition of Quality Gates](../yellow/definition-of-quality-gates.md) 23 | - [](#) [Test Containers Regarding Known Vulnerabilities](../green/test-container-images-regarding-known-vulnerabilities.md) 24 | 25 | ## Further Readings 26 | 27 | - Tool: [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/) 28 | 29 |

Send Feedback

30 | -------------------------------------------------------------------------------- /green/README.md: -------------------------------------------------------------------------------- 1 | # [](#) Green Belt 2 | 3 | The green belt introduces static code analysis as well as first activities ensuring security during the lifecycle of your software. It is also the first belt introducing topics regarding infrastructure, configuration, and credentials. 4 | 5 | - [Test for Default Credentials](test-for-default-credentials.md) 6 | - [Prevent Secrets in Source Code](prevent-secrets-in-source-code.md) 7 | - [Environment-Dependent Configuration Parameters](environment-dependent-configuration-parameters.md) 8 | - [Integration of Vulnerability Issues into the Development Process](integration-of-vulnerability-issues-into-the-development-process.md) 9 | - [Static Analysis for All Self-Written Components](static-analysis-for-all-self-written-components.md) 10 | - [Treatment of Vulnerabilities With Severity High or Higher](treatment-of-vulnerabilities-with-severity-high-or-higher.md) 11 | - [Test Container Images Regarding Known Vulnerabilities](test-container-images-regarding-known-vulnerabilities.md) 12 | - [Test Security Configuration of Cloud Environments](test-security-configuration-of-cloud-environments.md) 13 | - [Test Security Configuration of Infrastructure](test-security-configuration-of-infrastructure.md) 14 | - [Nightly Dependency Version Upgrade](nightly-dependency-version-upgrade.md) 15 | - [Ensure Only Using Components Which Are Under Active Development](ensure-only-using-components-which-are-under-active-development.md) 16 | 17 |

Send Feedback

18 | -------------------------------------------------------------------------------- /green/test-security-configuration-of-cloud-environments.md: -------------------------------------------------------------------------------- 1 | # Test Security Configuration of Cloud Environments 2 | 3 | ## Activities 4 | 5 | - Perform security tests against your cloud environments. 6 | - These should include IAM topics, logging/monitoring, access control, and system architecture. 7 | 8 | ## Benefits 9 | 10 | - The cloud environment is hardened against common attacks and misconfigurations. 11 | - Resilience of your application is increased. Following the *defense in depth* methodology. 12 | 13 | ## Assessment 14 | 15 | - Show the tests and usage of the tool(s). 16 | - Show the handling of the results. 17 | - Show the latest *n* findings. 18 | - Show your false positive list. 19 | 20 | ## Related Activities 21 | 22 | - [](#) [Continuous Integration](../yellow/continuous-integration.md) 23 | - [](#) [Unit Tests for Security Features](../yellow/unit-tests-for-security-features.md) 24 | - [](#) [Test for Default Credentials](../green/test-for-default-credentials.md) 25 | 26 | ## Further Readings 27 | 28 | - Tool: [Cloud Custodian](https://github.com/cloud-custodian/cloud-custodian) 29 | - Tool: [Awesome Cloud Security](https://github.com/4ndersonLin/awesome-cloud-security) 30 | 31 |

Send Feedback

32 | -------------------------------------------------------------------------------- /yellow/definition-of-quality-gates.md: -------------------------------------------------------------------------------- 1 | # Definition of Quality Gates 2 | 3 | ## Activities 4 | 5 | - Define quality gates adhering to your companies policy. 6 | - Make sure that all requirements are fulfilled. 7 | - Also define quality gates for found vulnerabilities and provide feedback about vulnerabilities and time of exposure, i.e., break the CI build. 8 | 9 | Be aware, by introducing this activity, you might have a backlog with many findings from the past. 10 | - Provide transparency about this backlog and continuously fix the reported issues. 11 | - Start with the most critical ones. 12 | - Make sure to adhere to the policy from now on and do not introduce additional findings through code changes. 13 | 14 | ## Benefits 15 | 16 | - Helps to find vulnerabilities earlier. As such, it helps to mitigate the risk of exploitation. This is important, as the risk of exploitation continuously increases over time for a given vulnerability. 17 | - Vulnerabilities are fixed in time. 18 | 19 | ## Assessment 20 | 21 | - Show the definition of the gates. 22 | - Show the usage of the gates. 23 | - Show the treatment of rejected cases. 24 | - Show your current exposure. 25 | - Show how you handle false positives. 26 | 27 | ## Related Activities 28 | 29 | - [](#) [Continuous Integration](../yellow/continuous-integration.md) 30 | 31 | ## Further Readings 32 | 33 | - Tool: [Jenkins Next Generation Warnings plugin](https://plugins.jenkins.io/warnings-ng/) 34 | 35 |

Send Feedback

36 | -------------------------------------------------------------------------------- /green/environment-dependent-configuration-parameters.md: -------------------------------------------------------------------------------- 1 | # Environment-Dependent Configuration Parameters 2 | 3 | ## Activities 4 | 5 | - Provide all environment-dependent configuration as parameters. 6 | - Avoid hard-coded environment-dependent data (e.g., credentials, paths) in application and infrastructure source code. 7 | 8 | ## Benefits 9 | 10 | - No leakage of confidential data through compromised source code. 11 | - Changing configurations of your application does not require source code changes and redeployment. 12 | - Credentials are not located in the version control system repositories. 13 | - The tested source code is the one which is deployed. No environment specific changes are required right before production deployment. Therefore, bugs introduced by these changes are prevented. 14 | 15 | ## Assessment 16 | 17 | - Show your configuration files for all your different environments like dev, test and production 18 | - URL specification for different environments 19 | - Configuration parameters for backend / database systems 20 | 21 | ## Related Activities 22 | 23 | - [](#) [Same Artifact for Environments](../orange/same-artifact-for-environments.md) 24 | - [](#) [Prevent Secrets in Source Code](../green/prevent-secrets-in-source-code.md) 25 | 26 | ## Further Readings 27 | 28 | - Tool: [SonarQube](https://www.sonarqube.org/) 29 | 30 |

Send Feedback

31 | -------------------------------------------------------------------------------- /blue/testing-for-bypassing-authentication-schema.md: -------------------------------------------------------------------------------- 1 | # Testing for Bypassing Authentication Schema 2 | 3 | A common mistake is to assume that authenticating a user only on the main page is sufficient and other locations don't require authentication, because every access occurs via the main page. 4 | 5 | ## Activities 6 | 7 | - Test that all resources delivered by your application require authentication, except for the public ones. 8 | - Leverage API specifications like [OpenAPI](https://www.openapis.org/) to discover all endpoints of your application. 9 | - Use tools to discover and access resources, e.g., [Gobuster](https://github.com/OJ/gobuster). 10 | 11 | ## Benefits 12 | 13 | - Ensure that private data is in fact not public. 14 | 15 | ## Assessment 16 | 17 | - Show your tests. 18 | - Show the usage of the tool(s). 19 | - Show the handling of the results. 20 | 21 | ## Related Activities 22 | 23 | - [](#) [Security Code Review](../yellow/security-code-review.md) 24 | - [](#) [Unit Tests for Security Features](../yellow/unit-tests-for-security-features.md) 25 | 26 | ## Further Readings 27 | 28 | - Tool: [Burp](https://portswigger.net/burp) 29 | - Tool: [OWASP ZAP](https://www.zaproxy.org/) 30 | - Tool: [ffuf](https://github.com/ffuf/ffuf) 31 | - Tool: [Gobuster](https://github.com/OJ/gobuster) 32 | - Specification: [OpenAPI](https://www.openapis.org/) 33 | 34 |

Send Feedback

35 | -------------------------------------------------------------------------------- /white/onboard-management-in-security.md: -------------------------------------------------------------------------------- 1 | # Onboard Management in Security 2 | 3 | Software vulnerabilities might be exploited when shipped into production. This results in risks for the organization. The person responsible for judging "risks vs. revenue" on your product (e.g., Product Owner, manager) must be convinced that continuously improving security through Security Belts is the best way to minimize risk and build better products. Judging about security risks requires company specific understanding about security risk management. Ensure that the aforementioned roles have this knowledge and train them if this is not the case. 4 | 5 | ## Activities 6 | 7 | - Convince your Product Owner to spend some time to roughly assess the current security of your product (e.g., collecting all security-related incidents and bugs). 8 | - Identify the persons who are judging "risks vs. revenue". 9 | - Raise the awareness of these persons (e.g., show how easy it is to exploit software). 10 | - Convince these persons that security is a continuous effort and that Security Belts are a cost efficient solution (e.g., by showing the results of your assessment). 11 | 12 | ## Benefits 13 | 14 | - The Product Owner is aware that software can have security vulnerabilities. 15 | - Resources are allocated to improve in security - to avoid, detect and fix security vulnerabilities. 16 | - Management can perform well informed decision when judging "risks vs. revenue". 17 | - The Product Owner has transparency on how secure the product is. 18 | 19 | ## Assessment 20 | 21 | - The white belt shall create the commitment to work on the Security Belts. Therefore, it does not require any assessment. 22 | 23 |

Send Feedback

24 | -------------------------------------------------------------------------------- /blue/get-to-know-your-design-flaws.md: -------------------------------------------------------------------------------- 1 | # Get to Know Your Design Flaws 2 | 3 | ## Activities 4 | 5 | - Review the design of your application regarding the [Security by Design Principles](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles). 6 | - Evaluate all violations of the design principles regarding their severity. 7 | - Analyze which violations lead to vulnerabilities. 8 | 9 | ## Benefits 10 | 11 | - Know vulnerabilities of your application. 12 | - Know where to get started when improving the resilience of your application. 13 | 14 | ## Assessment 15 | 16 | - Present your results. 17 | - Explain your next steps in dealing with these results. 18 | 19 | ## Related Activities 20 | 21 | - [](#) [Follow Security by Design Principles](../orange/follow-security-by-design-principles.md) 22 | - [](#) [Treatment of Vulnerabilities With Severity High or Higher](../green/treatment-of-vulnerabilities-with-severity-high-or-higher.md) 23 | - [](#) [Integration of Vulnerability Issues into the Development Process](../green/integration-of-vulnerability-issues-into-the-development-process.md) 24 | - [](#) [Conduction of Threat Modeling](../blue/conduction-of-threat-modeling.md) 25 | 26 |

Send Feedback

27 | -------------------------------------------------------------------------------- /blue/logging-concept.md: -------------------------------------------------------------------------------- 1 | # Logging Concept 2 | 3 | ## Activities 4 | 5 | - Improve or create the logging concept of your software. 6 | - Adhere to your logging concept in your software. 7 | - Start with your most critical application. 8 | 9 | Make sure your concept considers the following aspects: 10 | - Which data classification does your log data have? 11 | - Does your data include PII (personally identifiable information)? 12 | - Which regulatory requirements apply to your software? 13 | - How do you restrict the access to your log data? 14 | - How do you protect your log data against tampering? 15 | - What is the retention time of your log data? Consider: 16 | - Investigative purposes in case of a security incident. 17 | - Regulatory requirements. 18 | 19 | ## Benefits 20 | 21 | - Appropriate protection of log data. 22 | - Trustworthy log data: You reliably know what your application did last summer. 23 | - In case of an incident, you can comprehend the actions performed by the attacker(s). 24 | 25 | ## Assessment 26 | 27 | - Present your concept, answering the questions above. 28 | - Present the implementation of your concept. 29 | - Show the oldest irregularity in your logs. 30 | - Are you sure it is legal to log all these data? 31 | 32 | ## Related Activities 33 | 34 | - [](#) [Logging of Security Events](../orange/logging-of-security-events.md) 35 | - [](#) [Conduction of Threat Modeling](../blue/conduction-of-threat-modeling.md) 36 | 37 | ## Further Readings 38 | 39 | - Literature: [GDPR](https://gdpr.eu/) 40 | 41 |

Send Feedback

42 | -------------------------------------------------------------------------------- /orange/test-client-side-components-with-known-vulnerabilities.md: -------------------------------------------------------------------------------- 1 | # Test Client Side Components With Known Vulnerabilities 2 | 3 | ## Activities 4 | 5 | - Perform tests for known vulnerabilities in all third party client side software components (e.g., libs and frameworks) used by your software. 6 | - If possible, use tools to automate this task as much as possible. 7 | 8 | ## Benefits 9 | 10 | - Known vulnerabilities in used components are found and can be fixed. 11 | - The developed software is not vulnerable to well established attacks. 12 | 13 | ## Assessment 14 | 15 | - Show the tests and usage of the tool(s). 16 | - Show the handling of the results. 17 | - Show the latest *n* findings. 18 | - Show your false positive list. 19 | 20 | ## Related Activities 21 | 22 | - [](#) [Continuous Integration](../yellow/continuous-integration.md) 23 | - [](#) [Definition of Quality Gates](../yellow/definition-of-quality-gates.md) 24 | - [](#) [Test Components Regarding Known Vulnerabilities](../yellow/test-components-regarding-known-vulnerabilities.md) 25 | 26 | ## Further Readings 27 | 28 | - Tool: [OWASP Dependency Check](https://owasp.org/www-project-dependency-check) 29 | - Tool: [Retire.js](https://retirejs.github.io/retire.js) 30 | - Literature: [OWASP Top Ten: 9. Using Components with Known Vulnerabilities](https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities) 31 | 32 |

Send Feedback

33 | -------------------------------------------------------------------------------- /green/static-analysis-for-all-self-written-components.md: -------------------------------------------------------------------------------- 1 | # Static Analysis for All Self-Written Components 2 | 3 | ## Activities 4 | 5 | - Use static code analysis tools to find security vulnerabilities in all self-written source code. 6 | 7 | ## Benefits 8 | 9 | - Prevention of common vulnerabilities within your code during development. 10 | - Get early feedback to improve your code quality and avoid vulnerabilities in the future. 11 | 12 | ## Assessment 13 | 14 | - Show the usage of the tool(s). 15 | - Show the handling of the results. 16 | - Show the latest *n* findings. 17 | - Show your false positive list. 18 | 19 | ## Related Activities 20 | 21 | - [](#) [Continuous Integration](../yellow/continuous-integration.md) 22 | - [](#) [Definition of Quality Gates](../yellow/definition-of-quality-gates.md) 23 | 24 | ## Further Readings 25 | 26 | - Tool: [Contrast](https://www.contrastsecurity.com/) 27 | - Tool: [Spotbugs](https://spotbugs.github.io/) with [Find Security Bugs](https://find-sec-bugs.github.io/) 28 | - Tool: [SonarQube](https://www.sonarqube.org/) 29 | - Tool: [ESLint](https://eslint.org/) 30 | - Tool: [Amazon CodeGuru](https://aws.amazon.com/codeguru/) 31 | - Tool: [CogniCrypt](https://www.eclipse.org/cognicrypt/) 32 | - Literature: [OWASP Testing Guide 4.9.4](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption.html) 33 | - Literature: [Static Analysis Tool List](https://github.com/analysis-tools-dev/static-analysis) 34 | 35 |

Send Feedback

36 | -------------------------------------------------------------------------------- /green/nightly-dependency-version-upgrade.md: -------------------------------------------------------------------------------- 1 | # Nightly Dependency Version Upgrade 2 | 3 | ## Activities 4 | 5 | - Perform nightly upgrades of all dependencies (e.g., libraries) within the build process of your software. 6 | - Validate the latest dependency updates and upgrade the new dependencies in the repository after successful build and test process. 7 | 8 | ## Benefits 9 | 10 | - All software components are up-to-date and use dependencies with all available fixes for publicly known vulnerabilities. 11 | - Immediate benefit of bugfixes within the dependencies. 12 | - Early notification of deprecated functionality used by your software. 13 | 14 | ## Assessment 15 | 16 | - Show results of nightly upgrade process including successful and failed upgrades. 17 | 18 | ## Related Activities 19 | 20 | - [](#) [Test Components Regarding Known Vulnerabilities](../yellow/test-components-regarding-known-vulnerabilities.md) 21 | - [](#) [Nightly Test Libraries With Known Vulnerabilities](../orange/nightly-test-libraries-with-known-vulnerabilities.md) 22 | - [](#) [Test Container Images Regarding Known Vulnerabilities](../green/test-container-images-regarding-known-vulnerabilities.md) 23 | 24 | ## Further Readings 25 | 26 | - Tool: [Dependabot](https://dependabot.com/) 27 | - Literature: [OWASP Top Ten: 9. Using Components with Known Vulnerabilities](https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities) 28 | 29 |

Send Feedback

30 | -------------------------------------------------------------------------------- /blue/code-review.md: -------------------------------------------------------------------------------- 1 | # Code Review 2 | 3 | ## Activities 4 | 5 | - Perform code reviews of all code changes on software and infrastructure within the team. 6 | - Ensure that knowledge gained from the [Security Code Review](../yellow/security-code-review.md) is applied here. 7 | - Make sure that only approved changes are merged to your main branch within your version control system. A common solution is the use of pull requests in GitHub. 8 | 9 | ## Benefits 10 | 11 | - New vulnerabilities may be found before reaching production. 12 | - Old vulnerabilities are found and fixed. 13 | - Assurance of high code quality. 14 | 15 | ## Assessment 16 | 17 | - Present the established review process. 18 | - How are findings handled? 19 | - What conclusions/measures result from these reviews? 20 | - How is compliance with the process guaranteed? 21 | 22 | ## Related Activities 23 | 24 | - [](#) [Security Code Review](../yellow/security-code-review.md) 25 | - [](#) [Follow Security by Design Principles](../orange/follow-security-by-design-principles.md) 26 | - [](#) [Treatment of Vulnerabilities With Severity High or Higher](../green/treatment-of-vulnerabilities-with-severity-high-or-higher.md) 27 | 28 | ## Further Readings 29 | 30 | - Literature: [CWE Top 25 Most Dangerous Software Weaknesses](https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html) 31 | - Literature: [How to do a code review](https://google.github.io/eng-practices/review/reviewer/) 32 | 33 |

Send Feedback

34 | -------------------------------------------------------------------------------- /blue/dynamic-scan-for-security-vulnerabilities.md: -------------------------------------------------------------------------------- 1 | # Dynamic Scan for Security Vulnerabilities 2 | 3 | ## Activities 4 | 5 | - Use dynamic application security scanning tools to find security vulnerabilities in all components of your developed software. 6 | 7 | ## Benefits 8 | 9 | - Typical low hanging fruit vulnerabilities can be found and fixed. 10 | - The developed software is not vulnerable to well established attacks. 11 | 12 | ## Assessment 13 | 14 | - Show the usage of the tool(s). 15 | - Show the handling of the results. 16 | - Show the latest *n* findings. 17 | - Show your false positive list. 18 | 19 | ## Examples 20 | 21 | [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide) provides some general starting points you should cover, e.g.: 22 | 23 | - [4.5.1 Testing Directory Traversal File Include](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/05-Authorization_Testing/01-Testing_Directory_Traversal_File_Include.html) 24 | - [4.7.1 Testing for Reflected Cross Site Scripting](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.html) 25 | - [4.7.5 Testing for SQL Injection](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection.html) 26 | 27 | ## Related Activities 28 | 29 | - [](#) [Treatment of Vulnerabilities With Severity High or Higher](../green/treatment-of-vulnerabilities-with-severity-high-or-higher.md) 30 | 31 | ## Further Readings 32 | 33 | - Tool: [Burp](https://portswigger.net/burp) 34 | - Tool: [OWASP ZAP](https://www.zaproxy.org/) 35 | 36 |

Send Feedback

37 | -------------------------------------------------------------------------------- /green/test-security-configuration-of-infrastructure.md: -------------------------------------------------------------------------------- 1 | # Test Security Configuration of Infrastructure 2 | 3 | ## Activities 4 | 5 | - Perform security assessments of your server side infrastructure components. 6 | - These should include the operating system, middleware, application server, and database. 7 | - Be aware that these components might be running inside docker containers. 8 | 9 | ## Benefits 10 | 11 | - The infrastructure is hardened against common attacks and misconfigurations. 12 | - Resilience of your application is increased. Following the *defense in depth* methodology. 13 | 14 | ## Assessment 15 | 16 | - Show the assessment reports. 17 | - Show the handling of the results. 18 | - Show the latest *n* findings. 19 | - Show your false positive list. 20 | 21 | ## Related Activities 22 | 23 | - [](#) [Continuous Integration](../yellow/continuous-integration.md) 24 | - [](#) [Logging of Security Events](../orange/logging-of-security-events.md) 25 | - [](#) [Test for Default Credentials](../green/test-for-default-credentials.md) 26 | 27 | ## Further Readings 28 | 29 | - Literature: [CIS Benchmark](https://www.cisecurity.org/cis-benchmarks/) 30 | - Literature: [BSI IT-Grundschutz-Bausteine](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/IT-Grundschutz-Bausteine/Bausteine_Download_Edition_node.html) 31 | - Tool: [InSpec](https://www.chef.io/products/chef-inspec) 32 | - Tool: [nessus](https://www.tenable.com/products/nessus) 33 | - Tool: [OpenVAS](https://www.openvas.org/) 34 | 35 |

Send Feedback

36 | -------------------------------------------------------------------------------- /blue/regular-advanced-mob-hacking.md: -------------------------------------------------------------------------------- 1 | # Regular Advanced Mob Hacking 2 | 3 | ## Activities 4 | 5 | - Developers of your team participate in mob hacking sessions - organized by the Security Champion Guild - on a regular basis. 6 | - Train the identification and exploitation of vulnerabilities, by using an intercepting proxy, e.g., [Burp](https://portswigger.net/burp). 7 | 8 | Guidelines for your advanced mob hacking session: 9 | - Just like in mob programming, there is one driver and several navigators. 10 | - Basic technical and security knowledge is required. 11 | - Use an environment, where hacking is allowed and does not harm your production. 12 | - Use dedicated tools for intercepting/manipulating web requests, e.g., [Burp](https://portswigger.net/burp). 13 | - Use an insecure training app, e.g., [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/). 14 | - Encourage active participation, e.g., use small groups. 15 | - Allow enough time for understanding the identified exploits. 16 | - Track progress of the participants over time regarding relevant exploits. 17 | 18 | ## Benefits 19 | 20 | - The team improves their security knowledge. 21 | - The team understands advanced security threats, vulnerabilities, hacking methods, and security tools. 22 | - The team understands that even implemented security features can be insecure and exploitable. 23 | 24 | ## Assessment 25 | 26 | - Report on the experiences from the sessions. 27 | - Report on your lessons learned. 28 | 29 | ## Related Activities 30 | 31 | - [](#) [Simple Mob Hacking](../yellow/simple-mob-hacking.md) 32 | - [](#) [Regular Security Training for Everyone](../orange/regular-security-training-for-everyone.md) 33 | 34 | ## Further Readings 35 | 36 | - Tool: [DVWA](https://github.com/digininja/DVWA) 37 | - Tool: [OWASP Security Shepherd](https://owasp.org/www-project-security-shepherd/) 38 | - Tool: [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/) 39 | - Tool: [Awesome Vulnerable](https://github.com/kaiiyer/awesome-vulnerable) (list of tools) 40 | - Tool: [Burp](https://portswigger.net/burp) 41 | - Tool: [OWASP ZAP](https://www.zaproxy.org/) 42 | - Training: [Hack the Box](https://www.hackthebox.eu/) 43 | - Training: [Web Security Academy](https://portswigger.net/web-security) 44 | 45 |

Send Feedback

46 | -------------------------------------------------------------------------------- /yellow/unit-tests-for-security-features.md: -------------------------------------------------------------------------------- 1 | # Unit Tests for Security Features 2 | 3 | ## Activities 4 | 5 | - Identify all security-related features. These commonly contribute to the following security goals: 6 | - confidentiality 7 | - integrity 8 | - availability 9 | - authentication 10 | - authorization 11 | - accountability 12 | - Test functionality of these security-related features with unit tests. 13 | - Beware, unit tests should not only cover positive cases, but also negative cases (e.g., accessing admin resources as a normal user). 14 | 15 | ## Benefits 16 | 17 | - Arising vulnerabilities due to faulty code changes in security features can be found immediately. 18 | 19 | ## Assessment 20 | 21 | - Provide your unit tests for your security features and explain some of them. 22 | 23 | ## Examples 24 | 25 | [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide) provides some good examples, which can be covered by unit tests: 26 | 27 | - [4.4.7 Testing for Weak Password Policy](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy.html) 28 | 1. test for known passwords like $company2021, admin, $projectName, 123456, aaa 29 | 1. test for [breached passwords](https://github.com/danielmiessler/SecLists/tree/master/Passwords) 30 | - [4.5.3 Testing for Privilege Escalation](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation.html) 31 | 1. Acquire a session for a normal user. 32 | 1. Access admin functionality that the user should not be able to access. Use different values for all request parameters. 33 | - For each parameter define valid and invalid values. 34 | - Create tests for all combinations 35 | 1. Fail the test if you have access 36 | - [4.5.4 Testing for Insecure Direct Object References](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References.html) 37 | 1. Acquire a session for a normal user. 38 | 1. Get a reference to a document or resource accessible only by the user. 39 | 1. Acquire a second session for another user. 40 | 1. Use the reference to access the document or resource. 41 | 1. Fail the test if you have access 42 | 43 | ## Further Readings 44 | 45 | - Literature: [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide) 46 | 47 |

Send Feedback

48 | -------------------------------------------------------------------------------- /green/treatment-of-vulnerabilities-with-severity-high-or-higher.md: -------------------------------------------------------------------------------- 1 | # Treatment of Vulnerabilities With Severity High or Higher 2 | 3 | ## Activities 4 | 5 | - Focus on fixing the most relevant vulnerabilities without being overwhelmed of the potentially great number of low-impact findings. 6 | 7 | ## Benefits 8 | 9 | - Prioritized treatment of most severe vulnerabilities. 10 | - The software is free of high-impact vulnerabilities, which decreases the chance of successful denial of service attacks and loss or manipulation of confidential data. 11 | 12 | ## Assessment 13 | 14 | - Show the fix for the latest *n* high severity findings. 15 | - Show how you challenged the efficiency of the implemented fix. 16 | 17 | ## Related Activities 18 | 19 | - [](#) [False Positive Treatment](../yellow/false-positive-treatment.md) 20 | - [](#) [Test Components Regarding Known Vulnerabilities](../yellow/test-components-regarding-known-vulnerabilities.md) 21 | - [](#) [Unit Tests for Security Features](../yellow/unit-tests-for-security-features.md) 22 | - [](#) [Test Client Side Components With Known Vulnerabilities](../orange/test-client-side-components-with-known-vulnerabilities.md) 23 | - [](#) [Nightly Test Libraries With Known Vulnerabilities](../orange/nightly-test-libraries-with-known-vulnerabilities.md) 24 | - [](#) [Test Containers Images Regarding Known Vulnerabilities](../green/test-container-images-regarding-known-vulnerabilities.md) 25 | - [](#) [Static Analysis for All Self-Written Components](../green/static-analysis-for-all-self-written-components.md) 26 | 27 | ## Further Readings 28 | 29 | - Literature: [Security Knowledge Framework](https://www.securityknowledgeframework.org/) 30 | 31 |

Send Feedback

32 | -------------------------------------------------------------------------------- /orange/follow-security-by-design-principles.md: -------------------------------------------------------------------------------- 1 | # Follow Security by Design Principles 2 | 3 | ## Activities 4 | 5 | - Get to know the following Security by Design Principles: 6 | - [Least Privilege](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#least-privilege) 7 | - [Defense in Depth](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#defense-in-depth) 8 | - [Fail Securely](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#fail-securely) 9 | - [No Security by Obscurity](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#no-security-by-obscurity) 10 | - [Detect and Record](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#detect-and-record) 11 | - [Don't Trust](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#dont-trust) 12 | - [Keep It Simple](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#keep-it-simple) 13 | - [Secure the Weakest Link](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#secure-the-weakest-link) 14 | - [Decomposition](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#decomposition) 15 | - [Separation of Privilege](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#separation-of-privilege) 16 | - [Use Secure Defaults](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#use-secure-defaults) 17 | - [Don't Reinvent the Wheel](https://github.com/AppSecure-nrw/security-belts/wiki/Security-by-Design-Principles#dont-reinvent-the-wheel) 18 | - Build a common understanding within the team on how to implement these principles and integrate them into your development process. 19 | 20 | ## Benefits 21 | 22 | - The team has a common language and understanding of security principles. 23 | - Leverage proven security strategies to improve the resilience of your system. 24 | - Relevant security considerations are performed. 25 | - Security flaws can be discovered or prevented already in the design. 26 | 27 | ## Assessment 28 | 29 | - Explain the different Security by Design Principles. Each member of the team shall explain at least one principle. 30 | - Show (in code) how your implementation follows the principles. 31 | 32 | ## Examples 33 | 34 | For example, *Fail Securely* means whenever an error occurs in your software do not leak internal information and return into a state where the system is good to serve the next request. 35 | 36 | When implementing this principle: 37 | 38 | - Disable all debug output in production that is useful during development. 39 | - Configure middleware like application servers to not return version numbers, stacktrace, and technical error messages. 40 | - When receiving a malformed HTTP request, reject it rather than guessing the intended content. 41 | 42 | ## Related Activities 43 | 44 | - [](#) [Security Code Review](../yellow/security-code-review.md) 45 | 46 | ## Further Readings 47 | 48 | - [Security design with principles](https://medium.com/ouspg/security-design-with-principles-a8c045765b93) 49 | - [MITRE - Cyber Resiliency Design Principles](https://www.mitre.org/sites/default/files/2021-11/pr-17-0103-Cyber-Resiliency-Design-Principles.pdf) 50 | - [Agile Modellgetriebene Entwicklung von Software Security & Privacy - page 14 (german)](https://se-rwth.de/phdtheses/Diss-Hermerschmidt-Agile-Modellgetriebene-Entwicklung-von-Software-Security-and-Privacy.pdf) 51 | 52 |

Send Feedback

53 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | 2 | # Contributor Covenant Code of Conduct 3 | 4 | ## Our Pledge 5 | 6 | We as members, contributors, and leaders pledge to make participation in our 7 | community a harassment-free experience for everyone, regardless of age, body 8 | size, visible or invisible disability, ethnicity, sex characteristics, gender 9 | identity and expression, level of experience, education, socio-economic status, 10 | nationality, personal appearance, race, caste, color, religion, or sexual identity 11 | and orientation. 12 | 13 | We pledge to act and interact in ways that contribute to an open, welcoming, 14 | diverse, inclusive, and healthy community. 15 | 16 | ## Our Standards 17 | 18 | Examples of behavior that contributes to a positive environment for our 19 | community include: 20 | 21 | * Demonstrating empathy and kindness toward other people 22 | * Being respectful of differing opinions, viewpoints, and experiences 23 | * Giving and gracefully accepting constructive feedback 24 | * Accepting responsibility and apologizing to those affected by our mistakes, 25 | and learning from the experience 26 | * Focusing on what is best not just for us as individuals, but for the 27 | overall community 28 | 29 | Examples of unacceptable behavior include: 30 | 31 | * The use of sexualized language or imagery, and sexual attention or 32 | advances of any kind 33 | * Trolling, insulting or derogatory comments, and personal or political attacks 34 | * Public or private harassment 35 | * Publishing others' private information, such as a physical or email 36 | address, without their explicit permission 37 | * Other conduct which could reasonably be considered inappropriate in a 38 | professional setting 39 | 40 | ## Enforcement Responsibilities 41 | 42 | Community leaders are responsible for clarifying and enforcing our standards of 43 | acceptable behavior and will take appropriate and fair corrective action in 44 | response to any behavior that they deem inappropriate, threatening, offensive, 45 | or harmful. 46 | 47 | Community leaders have the right and responsibility to remove, edit, or reject 48 | comments, commits, code, wiki edits, issues, and other contributions that are 49 | not aligned to this Code of Conduct, and will communicate reasons for moderation 50 | decisions when appropriate. 51 | 52 | ## Scope 53 | 54 | This Code of Conduct applies within all community spaces, and also applies when 55 | an individual is officially representing the community in public spaces. 56 | Examples of representing our community include using an official e-mail address, 57 | posting via an official social media account, or acting as an appointed 58 | representative at an online or offline event. 59 | 60 | ## Enforcement 61 | 62 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 63 | reported to the community leaders responsible for enforcement at 64 | security-belts@iem.fraunhofer.de. 65 | All complaints will be reviewed and investigated promptly and fairly. 66 | 67 | All community leaders are obligated to respect the privacy and security of the 68 | reporter of any incident. 69 | 70 | ## Enforcement Guidelines 71 | 72 | Community leaders will follow these Community Impact Guidelines in determining 73 | the consequences for any action they deem in violation of this Code of Conduct: 74 | 75 | ### 1. Correction 76 | 77 | **Community Impact**: Use of inappropriate language or other behavior deemed 78 | unprofessional or unwelcome in the community. 79 | 80 | **Consequence**: A private, written warning from community leaders, providing 81 | clarity around the nature of the violation and an explanation of why the 82 | behavior was inappropriate. A public apology may be requested. 83 | 84 | ### 2. Warning 85 | 86 | **Community Impact**: A violation through a single incident or series 87 | of actions. 88 | 89 | **Consequence**: A warning with consequences for continued behavior. No 90 | interaction with the people involved, including unsolicited interaction with 91 | those enforcing the Code of Conduct, for a specified period of time. This 92 | includes avoiding interactions in community spaces as well as external channels 93 | like social media. Violating these terms may lead to a temporary or 94 | permanent ban. 95 | 96 | ### 3. Temporary Ban 97 | 98 | **Community Impact**: A serious violation of community standards, including 99 | sustained inappropriate behavior. 100 | 101 | **Consequence**: A temporary ban from any sort of interaction or public 102 | communication with the community for a specified period of time. No public or 103 | private interaction with the people involved, including unsolicited interaction 104 | with those enforcing the Code of Conduct, is allowed during this period. 105 | Violating these terms may lead to a permanent ban. 106 | 107 | ### 4. Permanent Ban 108 | 109 | **Community Impact**: Demonstrating a pattern of violation of community 110 | standards, including sustained inappropriate behavior, harassment of an 111 | individual, or aggression toward or disparagement of classes of individuals. 112 | 113 | **Consequence**: A permanent ban from any sort of public interaction within 114 | the community. 115 | 116 | ## Attribution 117 | 118 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], 119 | version 2.1, available at 120 | [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. 121 | 122 | Community Impact Guidelines were inspired by 123 | [Mozilla's code of conduct enforcement ladder][Mozilla CoC]. 124 | 125 | For answers to common questions about this code of conduct, see the FAQ at 126 | [https://www.contributor-covenant.org/faq][FAQ]. Translations are available 127 | at [https://www.contributor-covenant.org/translations][translations]. 128 | 129 | [homepage]: https://www.contributor-covenant.org 130 | [v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html 131 | [Mozilla CoC]: https://github.com/mozilla/diversity 132 | [FAQ]: https://www.contributor-covenant.org/faq 133 | [translations]: https://www.contributor-covenant.org/translations 134 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![GitHub release](https://img.shields.io/github/v/release/AppSecure-nrw/security-belts)](https://github.com/AppSecure-nrw/security-belts/releases) 2 | [![Check Markdown Links](https://github.com/AppSecure-nrw/security-belts/actions/workflows/check-md-links.yml/badge.svg)](https://github.com/AppSecure-nrw/security-belts/actions/workflows/check-md-links.yml?query=branch%3Amaster) 3 | [![Spell Check](https://github.com/AppSecure-nrw/security-belts/actions/workflows/check-spell.yml/badge.svg)](https://github.com/AppSecure-nrw/security-belts/actions/workflows/check-spell.yml?query=branch%3Amaster) 4 |
5 | 6 | # Security Belts 7 | 8 | [](white/README.md) 9 | [](yellow/README.md) 10 | [](orange/README.md) 11 | [](green/README.md) 12 | [](blue/README.md) 13 | [](purple/README.md) 14 | [](red/README.md) 15 | [](brown/README.md) 16 | [](black/README.md) 17 | 18 | The maturity model *Security Belts* structures activities of the secure software development and, thus, offers development teams a good opportunity to address the topic and to build up necessary competencies to ensure the software security of their products. Thereby, the maturity model supports development teams that are overwhelmed with the duty to take over much more responsibility without having sufficient competencies in the team. 19 | 20 | For detailed information on the methodology behind the model, please take a look at our [Wiki](https://github.com/AppSecure-nrw/security-belts/wiki). 21 | 22 | In order to continuously improve the Security Belts model, we appreciate any kind of feedback or content contribution. If you are interested in contributing, please see the document [Contributing](CONTRIBUTING.md). 23 | 24 | ## Belts 25 | 26 | Working on the belts is a continuous effort. Start with the first belt, the white one, and keep working on them, until you achieve the desired belt for your team. Activities of later belts often relate to activities introduced in previous belts. In this case, the previous relevant belt activities will be highlighted for the belt activity. 27 | 28 | - [](white/README.md) [White Belt](white/README.md) 29 | - [](yellow/README.md) [Yellow Belt](yellow/README.md) 30 | - [](orange/README.md) [Orange Belt](orange/README.md) 31 | - [](green/README.md) [Green Belt](green/README.md) 32 | - [](blue/README.md) [Blue Belt](blue/README.md) 33 | - [](purple/README.md) [Purple Belt](purple/README.md) 34 | - [](red/README.md) [Red Belt](red/README.md) 35 | - [](brown/README.md) [Brown Belt](brown/README.md) 36 | - [](black/README.md) [Black Belt](black/README.md) 37 | 38 | ## Getting Started 39 | 40 | This getting started is primarily aimed at developers. 41 | 42 | - Become familiar with our [Security Belts concepts](https://github.com/AppSecure-nrw/security-belts/wiki/The-Concept) such that you can explain them to your colleagues. In the future, we will provide slides to ease this task. 43 | - Identify colleagues (developers, Product Owners, managers) in your company that already want to improve the secure software development. They can discuss with you how to implement security belts in your company. Found the [Security Champion Guild](https://github.com/AppSecure-nrw/security-belts/wiki/Security-Champion-Guild) with them. 44 | - Persuade your team to start working on the [White Belt](white/README.md). 45 | 46 | ## Credits 47 | 48 | The Security Belts are based on the [OWASP DevSecOps Maturity Model](https://owasp.org/www-project-devsecops-maturity-model/) and partially inspired by [OWASP SAMM](https://owasp.org/www-project-samm/) 49 | 50 | This work is part of the research project "AppSecure.nrw - Security-by-Design of Java-based Applications". The project is funded by the European Regional Development Fund (ERDF-0801379). 51 |
52 |
AppSecure.nrw Logo 53 | 54 | EFRE Logo NRW Logo 55 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public licenses. 411 | Notwithstanding, Creative Commons may elect to apply one of its public 412 | licenses to material it publishes and in those instances will be 413 | considered the “Licensor.” The text of the Creative Commons public 414 | licenses is dedicated to the public domain under the CC0 Public Domain 415 | Dedication. Except for the limited purpose of indicating that material 416 | is shared under a Creative Commons public license or as otherwise 417 | permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the public 425 | licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | --------------------------------------------------------------------------------