Contributing to the Playbook

The SAP Pentest Playbook is community-driven - contributions from security practitioners, researchers, and ethical hackers are welcome.

It uses Geekdocs for visualization of the Playbook, which is a static site generator built on top of Hugo.

Ways you can contribute:

• Submit new techniques, tools, or case studies
• Update outdated content with current SAP versions and security measures
• Add detection and mitigation tips for the techniques described
• Review and improve documentation structure for clarity and usability

To keep the Playbook trustworthy, every contribution should meet these standards:

• Verified, not hearsay. Ground claims in primary sources - SAP Notes, official SAP documentation, CVE/NVD records, or named public research. Cite them in the page’s References section. If something is a reasoned hypothesis rather than a confirmed technique, say so explicitly.
• No zero-days. Only document vulnerabilities and techniques that are already public and responsibly disclosed in line with SAP’s disclosure policy. Do not submit non-public exploit detail.
• Attack paired with defense. Every technique needs Mitigation and Detection and Monitoring guidance - a page that only shows how to attack is not complete.
• Reproducible and in scope. Prefer techniques a tester can reproduce in a customer-operated environment. SAP-managed SaaS-only issues can be included as background/context but should be marked as such, not written as reproducible steps (see scope).
• Lead with an existing PoC. When a public proof-of-concept or tool already implements a technique, reference it rather than re-implementing - especially for cryptographic operations.

Content is written in Markdown and follows a fixed set of page types. Start from the matching template and fill in your details:

• Known attack vector - the core technique pages (template_know-attack-vector.md). Shape: Description → Risk → Options → Mitigation → Detection and Monitoring → References.
• Reconnaissance - discovery/fingerprinting pages (template_reconnaissance.md). Lighter shape: Description → Options → References.
• Object - a system/service reference an attack-vector page links to (template_object.md).
• Option - a reusable technique/option building block (template_option.md).

Note

Templates live in the template folder. Copy the right one into the relevant platform folder and fill it in. Keep the tone factual and match the style of the surrounding pages; put links and sources at the end of the page in References.

Before opening a PR, render the site locally to check formatting, links, and navigation. A one-command Docker setup lives in the dev/ folder — it needs only Docker, no local Hugo or Node install:

cd dev
docker compose up

Then open http://localhost:1313. Edits under content/ rebuild and live-reload in the browser. It runs a recent Hugo (extended) build, so what you see locally closely matches what the pipeline builds.

Note

The theme (hugo-geekdoc) is a git submodule and ships source only — its CSS/JS assets are generated by a Node build. The Docker setup handles this for you. If you prefer a native toolchain (Hugo ≥ 0.124 + Node 20), clone with --recursive and build the theme assets first — see dev/README.md for the exact steps. A plain clone without the submodule/asset build renders the site unstyled.

Some techniques touch unpatched issues, weaponizable exploit detail, or anti-forensics. For these:

• Frame the page around what to test for, what to patch, and what to monitor - the defensive value - rather than a turn-key weaponized exploit.
• For an unpatched primitive (no vendor fix available), coordinate with the project leads before publishing exploit detail.
• Anti-forensics / detection-evasion techniques should be documented from the defender’s perspective (how to detect them), not as an evasion how-to.

If you’re unsure whether something crosses a line, open a draft PR or ask in Discord before publishing.

1. Fork the repository and create a feature branch.
2. Add your contribution in the relevant section of the Playbook (Markdown format), starting from the matching template.
3. Include references, screenshots, or code samples where applicable - and complete the References section.
4. Commit with a sign-off (git commit -s) - see below.
5. Submit a pull request; the PR template’s checklist mirrors the quality bar above.
6. A project maintainer reviews for accuracy, sourcing, scope, and the attack-paired-with-defense requirement before merge.

Issue and pull-request templates are provided in .github/ to standardize submissions - use “New technique / content proposal” or “Correction / update” when opening an issue.

Contributions are accepted under the Developer Certificate of Origin (DCO) - a lightweight, per-commit sign-off that certifies you have the right to submit the contribution. It requires no separate agreement or bot.

Add a sign-off line to each commit with the -s flag:

git commit -s -m "Add detection guidance for X"

This appends a Signed-off-by: Your Name <you@example.com> line (matching your git identity) to the commit message, certifying the DCO. Commits without a sign-off will be asked to amend before merge.

The Playbook is published under Creative Commons Attribution 4.0 International (CC BY 4.0). By contributing, you agree that your contribution is licensed under the same terms.

• Geekdocs Documentation
• Template folder
• OWASP CBAS project