OWASP Cheat Sheet Seriesは、アプリケーションセキュリティの実務知識を92件のMarkdownドキュメントにまとめたナレッジベースです。認証・認可・暗号化・XSS対策など個別テーマごとに、要点と実装コード例を簡潔にまとめています。リポジトリ自体はソフトウェアではなく、mkdocsで静的サイトに変換される文書集です。
中身はcheatsheets/配下のMarkdownファイル群で、Index.mdやIndexASVS.mdなどのインデックスファイルがテーマ別・標準別に一覧を提供します。requirements.txtに列挙されたmkdocs・mkdocs-materialを使い、Makefileの`make generate-site`でHTML静的サイトを生成し、`make serve`でポート8000にローカル配信します。品質担保の仕組みが厳格で、markdownlintとtextlint(用語統一)によるリンティング、md-link-check.ymlによるリンク切れ検査、citation-check.ymlによる新規セクションの引用元(RFCやNIST文書など)必須チェックが、それぞれGitHub Actionsで自動実行されます。さらに.claude/agents配下にはPRレビュー用のエージェント定義(重複チェック・言語レビュー・リンク監査・実用性レビュー・セキュリティレビュー)があり、CLAUDE.mdの手順に沿ってAIレビューを補助的に使う運用になっています。master pushをトリガーにbuild-and-deploy-website.ymlがサイトをビルドし、gh-pagesブランチへ自動デプロイします。
- STEP 01
`make install-python-requirements`を実行すると、requirements.txtにあるmkdocs・mkdocs-material・lxmlなど20個以上のPythonパッケージがインストールされます。
- STEP 02
`make generate-site`を実行すると、scripts配下のGenerate_Site_mkDocs.shが動き、cheatsheets/内のMarkdownからgenerated/site/にHTML一式が作られます。
- STEP 03
`make serve`でポート8000にサイトが立ち上がり、ブラウザでIndex.md相当のトップページから92件のチートシートを閲覧できます。
- STEP 04
`npm run lint-markdown`と`npm run lint-terminology`を回すと、.markdownlint.jsonと.textlintrcのルールに沿った表記揺れ・用語違反が指摘されます。
- STEP 05
Dockerを使う場合は`docker build -t cheatsheetseries .`のあと`docker run -p 8000:8000`でコンテナ内から同じサイトが立ち上がります。
- STEP 06
新しいチートシートをPRで出すと、citation-check.ymlが新規のH2見出しに外部リンク(RFC・NIST・OWASP標準など)の引用があるかを自動判定します。
手元に残るのは、実行可能なアプリではなく、ローカルサーバー上で閲覧できる静的なセキュリティ知識サイトです。Access ControlやAuthentication、XSS対策、暗号ストレージなど92件のテーマ別ページと、それぞれのコード例(assets/にあるJavaサンプルや図版を含む)が手に入ります。CI設定一式を見ることで、OWASPがどのように文書品質(表記統一・リンク健全性・引用の裏付け)を担保しているかも把握できます。
READMEにも明記されている通り、Markdownファイル自体は作業用ソースであり、外部文書での直接参照は想定されていません。公式サイトの内容を正として使うべきです。
このリポジトリはコードを実行するツールではなくドキュメント集なので、`make serve`で得られるのはあくまで閲覧用サイトであり、セキュリティ機能そのものを提供するわけではありません。
citation-check.ymlは新規追加されたH2セクションのみを対象にしており、既存の全セクションに引用があることを保証するものではありません。
Dockerfileはpython:3.14-slimベースで、libxml2-devなどのビルド依存を含むため、初回ビルドに一定の時間がかかります。
アプリケーションのセキュリティ実装時にリファレンスを探している開発者・セキュレビューアーには有用な資料集です。認証やXSS対策など、テーマごとにOWASPがまとめた実装指針とコード例を、公式サイトかローカルビルドのどちらでも参照できます。判断材料としては、markdownlint・textlint・リンク切れ検査・引用チェックの4系統がGitHub Actionsで自動化されている点、CODEOWNERSで各チートシートの責任者が明記されている点から、内容の継続的な品質管理体制が確認できます。実際にインストールしなくても、Makefileとrequirements.txtの構成、CI workflowファイルの中身から、ビルド手順と品質ゲートの実在性は読み取れるため、この判断は十分信頼できます。