diff --git a/.github/ISSUE_TEMPLATE/bug-report.yml b/.github/ISSUE_TEMPLATE/bug-report.yml new file mode 100644 index 0000000..113ee8d --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug-report.yml @@ -0,0 +1,37 @@ +name: Bug Report +description: Report an error or inconsistency in the standard +labels: ["bug"] +body: + - type: markdown + attributes: + value: | + Thanks for taking the time to report an issue with the TCASVS. + - type: input + id: location + attributes: + label: Location + description: Which chapter, section, or requirement ID is affected? + placeholder: "e.g., V3.2.1 or 0x12-V3-Data-Storage-and-Protection.md" + validations: + required: true + - type: textarea + id: description + attributes: + label: Description + description: Describe the issue clearly. + placeholder: What is wrong and what should it say instead? + validations: + required: true + - type: dropdown + id: type + attributes: + label: Issue type + options: + - Incorrect requirement text + - Missing CWE mapping + - Incorrect level assignment + - Formatting/layout issue + - Broken link + - Other + validations: + required: true diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml new file mode 100644 index 0000000..de953e3 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -0,0 +1,5 @@ +blank_issues_enabled: true +contact_links: + - name: OWASP Slack + url: https://owasp.slack.com + about: Join the OWASP Slack workspace to discuss the TCASVS with the community diff --git a/.github/ISSUE_TEMPLATE/new-requirement.yml b/.github/ISSUE_TEMPLATE/new-requirement.yml new file mode 100644 index 0000000..306fb8c --- /dev/null +++ b/.github/ISSUE_TEMPLATE/new-requirement.yml @@ -0,0 +1,48 @@ +name: New Requirement Proposal +description: Propose a new security requirement for inclusion in the TCASVS +labels: ["enhancement", "new-requirement"] +body: + - type: markdown + attributes: + value: | + Use this template to propose a new requirement. Please provide enough context for the working group to evaluate the proposal. + - type: input + id: chapter + attributes: + label: Target Chapter + description: Which chapter should this requirement belong to? + placeholder: "e.g., V3 Data Storage and Protection" + validations: + required: true + - type: textarea + id: requirement + attributes: + label: Proposed Requirement + description: Write the requirement in TCASVS format (start with "Verify that..."). + placeholder: "Verify that the application..." + validations: + required: true + - type: dropdown + id: level + attributes: + label: Suggested Level + description: At which verification level should this apply? + options: + - L1 (all applications) + - L2 (sensitive data) + - L3 (high security) + validations: + required: true + - type: textarea + id: rationale + attributes: + label: Rationale + description: Why is this requirement needed? Reference attack scenarios, CWEs, or real-world incidents. + validations: + required: true + - type: input + id: cwe + attributes: + label: CWE Mapping + description: Related CWE ID(s) if known. + placeholder: "e.g., CWE-312" diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 4f057bd..361a49f 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -1,9 +1,13 @@ -name: Convert Markdown to PDF and Create Release +name: Build and Release TCASVS on: push: branches: - main + paths: + - '5.0/en/**' + - '5.0/tools/**' + - '5.0/Makefile' jobs: build: @@ -11,23 +15,37 @@ jobs: steps: - name: Checkout repository - uses: actions/checkout@v6 + uses: actions/checkout@v4 - - name: Set up Pandoc and jq + - name: Set up Python + uses: actions/setup-python@v5 + with: + python-version: '3.12' + + - name: Install system dependencies run: | sudo apt-get update - sudo apt-get install -y pandoc texlive jq + sudo apt-get install -y pandoc texlive-xetex texlive-fonts-recommended jq + + - name: Install Python dependencies + run: pip install dicttoxml2 + + - name: Verify requirements parse correctly + working-directory: 5.0 + run: | + python tools/export.py --verify-only --format json --language en + python tools/export.py --verify-only --format csv --language en - - name: Fetch the latest release + - name: Build all exports + working-directory: 5.0 + run: make all + + - name: Fetch the latest release tag id: fetch_latest_release run: | LATEST_TAG=$(curl -s https://api.github.com/repos/${{ github.repository }}/releases/latest | jq -r .tag_name) if [ -z "$LATEST_TAG" ] || [ "$LATEST_TAG" == "null" ]; then - LATEST_TAG="v0.4.0" - fi - # using this to fake/bump versions to v1.0 - if [ "$LATEST_TAG" == "v0.4.0" ]; then - LATEST_TAG="v1.0" + LATEST_TAG="v5.0.0" fi echo "LATEST_TAG=$LATEST_TAG" >> $GITHUB_ENV @@ -35,18 +53,12 @@ jobs: id: increment_version run: | LATEST_TAG=${{ env.LATEST_TAG }} - echo "Latest tag: $LATEST_TAG" LATEST_VERSION=${LATEST_TAG#v} - IFS='.' read -r major minor <<< "$LATEST_VERSION" - NEW_VERSION="$major.$((minor + 1))" + IFS='.' read -r major minor patch <<< "$LATEST_VERSION" + NEW_VERSION="$major.$minor.$((patch + 1))" NEW_TAG="v$NEW_VERSION" - echo "New version: $NEW_TAG" echo "NEW_TAG=$NEW_TAG" >> $GITHUB_ENV - - name: Concatenate and Convert Markdown to PDF - run: | - pandoc document/1.0/*.md -o TASVS-${{ env.NEW_TAG }}.pdf -V geometry:margin=2cm - - name: Create GitHub Release id: create_release uses: actions/create-release@v1 @@ -54,16 +66,56 @@ jobs: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: tag_name: ${{ env.NEW_TAG }} - release_name: Release ${{ env.NEW_TAG }} + release_name: TCASVS ${{ env.NEW_TAG }} draft: false prerelease: false - - name: Upload PDF to Release + - name: Upload PDF uses: actions/upload-release-asset@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: upload_url: ${{ steps.create_release.outputs.upload_url }} - asset_path: ./TASVS-${{ env.NEW_TAG }}.pdf - asset_name: TASVS-${{ env.NEW_TAG }}.pdf + asset_path: ./5.0/dist/OWASP_Thick_Client_Application_Security_Verification_Standard_5.0.0_en.pdf + asset_name: TCASVS-${{ env.NEW_TAG }}.pdf asset_content_type: application/pdf + + - name: Upload DOCX + uses: actions/upload-release-asset@v1 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + with: + upload_url: ${{ steps.create_release.outputs.upload_url }} + asset_path: ./5.0/dist/OWASP_Thick_Client_Application_Security_Verification_Standard_5.0.0_en.docx + asset_name: TCASVS-${{ env.NEW_TAG }}.docx + asset_content_type: application/vnd.openxmlformats-officedocument.wordprocessingml.document + + - name: Upload JSON + uses: actions/upload-release-asset@v1 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + with: + upload_url: ${{ steps.create_release.outputs.upload_url }} + asset_path: ./5.0/dist/OWASP_Thick_Client_Application_Security_Verification_Standard_5.0.0_en.json + asset_name: TCASVS-${{ env.NEW_TAG }}.json + asset_content_type: application/json + + - name: Upload CSV + uses: actions/upload-release-asset@v1 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + with: + upload_url: ${{ steps.create_release.outputs.upload_url }} + asset_path: ./5.0/dist/OWASP_Thick_Client_Application_Security_Verification_Standard_5.0.0_en.csv + asset_name: TCASVS-${{ env.NEW_TAG }}.csv + asset_content_type: text/csv + + - name: Upload CycloneDX + uses: actions/upload-release-asset@v1 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + with: + upload_url: ${{ steps.create_release.outputs.upload_url }} + asset_path: ./5.0/dist/OWASP_Thick_Client_Application_Security_Verification_Standard_5.0.0_en.cdx.json + asset_name: TCASVS-${{ env.NEW_TAG }}.cdx.json + asset_content_type: application/json diff --git a/.gitignore b/.gitignore index 80180de..08c3ef9 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,6 @@ /Gemfile /Gemfile.lock /favicon.ico -_site/ \ No newline at end of file +_site/ +__pycache__/ +*.pyc \ No newline at end of file diff --git a/.markdownlint.jsonc b/.markdownlint.jsonc new file mode 100644 index 0000000..7f3590a --- /dev/null +++ b/.markdownlint.jsonc @@ -0,0 +1,22 @@ +{ + "default": true, + "MD013": { + "line_length": 500, + "tables": false + }, + "MD024": { + "siblings_only": true + }, + "MD033": { + "allowed_elements": [ + "a", + "img", + "div", + "b", + "sup", + "u", + "br" + ] + }, + "MD041": false +} diff --git a/5.0/Makefile b/5.0/Makefile new file mode 100644 index 0000000..d68899d --- /dev/null +++ b/5.0/Makefile @@ -0,0 +1,97 @@ +# TCASVS Build System +# Generates PDF, DOCX, JSON, CSV, XML, and CycloneDX outputs from source Markdown. + +PROJDIR := $(realpath $(CURDIR)) +TOOLSDIR := tools +TEMPLATEDIR := templates +SOURCEDIR := en +BUILDDIR := build +DISTDIR := dist + +TARGETNAME := OWASP_Thick_Client_Application_Security_Verification_Standard_5.0.0_ + +# Source files +SOURCE_FILES := $(sort $(wildcard $(SOURCEDIR)/0x*.md $(SOURCEDIR)/0x*.yaml)) +BUILD_FILES := $(patsubst $(SOURCEDIR)/%, $(BUILDDIR)/%, $(SOURCE_FILES)) + +# Output targets +MD_FILE := $(DISTDIR)/$(TARGETNAME)en.md +PDF_FILE := $(DISTDIR)/$(TARGETNAME)en.pdf +DOCX_FILE := $(DISTDIR)/$(TARGETNAME)en.docx +JSON_FILE := $(DISTDIR)/$(TARGETNAME)en.json +JSON_FLAT_FILE := $(DISTDIR)/$(TARGETNAME)en.flat.json +CSV_FILE := $(DISTDIR)/$(TARGETNAME)en.csv +XML_FILE := $(DISTDIR)/$(TARGETNAME)en.xml +CDX_FILE := $(DISTDIR)/$(TARGETNAME)en.cdx.json + +EXPORT_TOOL := $(TOOLSDIR)/export.py + +# Pandoc flags +PANDOC_PDF_FLAGS := -f markdown -s -t latex --pdf-engine=xelatex +PANDOC_DOCX_FLAGS := -s -t docx -f markdown --toc --columns 10000 \ + --reference-doc=$(TEMPLATEDIR)/reference.docx + +.PHONY: all pdf docx json json_flat csv xml cdx_json md clean verify + +all: md pdf docx json json_flat csv xml cdx_json + +$(BUILDDIR): + mkdir -p $@ + +$(DISTDIR): + mkdir -p $@ + +# Transform source MD (add CWE hyperlinks, fix image paths) +$(BUILDDIR)/%.md: $(SOURCEDIR)/%.md | $(BUILDDIR) + sed -E 's#(\| ?)([0-9]{2,4})( ?\|)#\1[\2](https://cwe.mitre.org/data/definitions/\2.html)\3#g' $< > $@ + +$(BUILDDIR)/%.yaml: $(SOURCEDIR)/%.yaml | $(BUILDDIR) + cp $< $@ + +# Merged Markdown +md: $(MD_FILE) +$(MD_FILE): $(BUILD_FILES) | $(DISTDIR) + pandoc -f gfm -s -t markdown -o $@ $(BUILDDIR)/0x*.md + +# PDF via LaTeX +pdf: $(PDF_FILE) +$(PDF_FILE): $(BUILD_FILES) | $(DISTDIR) + pandoc $(PANDOC_PDF_FLAGS) \ + --include-in-header=$(TEMPLATEDIR)/header-eisvogel.tex \ + -o $@ --template $(TEMPLATEDIR)/eisvogel.tex \ + $(BUILDDIR)/0x*.md $(SOURCEDIR)/0x00-Header.yaml + +# DOCX +docx: $(DOCX_FILE) +$(DOCX_FILE): $(BUILD_FILES) | $(DISTDIR) + pandoc $(PANDOC_DOCX_FLAGS) -o $@ $(BUILDDIR)/0x*.md $(SOURCEDIR)/0x00-Header.yaml + +# Structured exports via Python +json: $(JSON_FILE) +$(JSON_FILE): $(SOURCE_FILES) | $(DISTDIR) + cd $(PROJDIR) && python3 $(EXPORT_TOOL) --format json --language $(SOURCEDIR) > $@ + +json_flat: $(JSON_FLAT_FILE) +$(JSON_FLAT_FILE): $(SOURCE_FILES) | $(DISTDIR) + cd $(PROJDIR) && python3 $(EXPORT_TOOL) --format json_flat --language $(SOURCEDIR) > $@ + +csv: $(CSV_FILE) +$(CSV_FILE): $(SOURCE_FILES) | $(DISTDIR) + cd $(PROJDIR) && python3 $(EXPORT_TOOL) --format csv --language $(SOURCEDIR) > $@ + +xml: $(XML_FILE) +$(XML_FILE): $(SOURCE_FILES) | $(DISTDIR) + cd $(PROJDIR) && python3 $(EXPORT_TOOL) --format xml --language $(SOURCEDIR) > $@ + +cdx_json: $(CDX_FILE) +$(CDX_FILE): $(SOURCE_FILES) | $(DISTDIR) + cd $(PROJDIR) && python3 $(EXPORT_TOOL) --format cdx_json --language $(SOURCEDIR) > $@ + +# Verification +verify: $(SOURCE_FILES) + cd $(PROJDIR) && python3 $(EXPORT_TOOL) --verify-only --format json --language $(SOURCEDIR) + cd $(PROJDIR) && python3 $(EXPORT_TOOL) --verify-only --format csv --language $(SOURCEDIR) + +# Clean +clean: + rm -rf $(BUILDDIR) $(DISTDIR) diff --git a/5.0/docs_en/README.md b/5.0/docs_en/README.md new file mode 100644 index 0000000..2f1fe2e --- /dev/null +++ b/5.0/docs_en/README.md @@ -0,0 +1,26 @@ +# Compiled Outputs + +This directory contains auto-generated output files for the TCASVS standard. + +## Available Formats + +The following formats are generated by the CI pipeline and attached to GitHub Releases: + +- **PDF** — Paginated document for offline reading +- **DOCX** — Editable Word format for review workflows +- **CSV** — Flat requirement list for spreadsheet tooling +- **JSON** — Machine-readable structured export +- **CycloneDX JSON** — SBOM-compatible requirement representation + +## Generating Locally + +```bash +cd ../ +make +``` + +Output files will be placed in `dist/`. See [COMPILING.md](../../COMPILING.md) for full instructions. + +## Note + +Do not commit generated files to this directory manually. They are produced by the `main.yml` GitHub Actions workflow and published as release artifacts. diff --git a/5.0/en/0x00-Header.yaml b/5.0/en/0x00-Header.yaml new file mode 100644 index 0000000..e4bbda3 --- /dev/null +++ b/5.0/en/0x00-Header.yaml @@ -0,0 +1,15 @@ +--- + title: "Thick Client Application Security Verification Standard" + subtitle: "Version 5.0.0" + date: 2026 + titlepage: true + titlepage-rule-height: 0 + titlepage-logo: "images/owasp_logo_1c_notext.png" + table-use-row-colors: true + toc: true + toc-own-page: true + geometry: "left=2cm,right=2cm,top=3cm,bottom=3cm" + CJKmainfont: "Noto Sans CJK JP" + mainfont: "Source Serif 4" + sansfont: "Source Sans 3" +--- diff --git a/5.0/en/0x01-Frontispiece.md b/5.0/en/0x01-Frontispiece.md new file mode 100644 index 0000000..7ad1501 --- /dev/null +++ b/5.0/en/0x01-Frontispiece.md @@ -0,0 +1,35 @@ +# Frontispiece + +## About the Standard + +The Thick Client Application Security Verification Standard is a list of application security requirements or tests that can be used by architects, developers, testers, security professionals, tool vendors, and consumers to define, build, test, and verify secure thick client applications. + +## Copyright and License + +Version 5.0.0, 2026 + +![license](../images/license.png) + +Copyright © 2024-2026 The OWASP Foundation. + +This document is released under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). For any reuse or distribution, you must make clear to others the license terms of this work. + +## Project Leaders + +| | +|---------------| +| Dave Hanson | +| Samuel Aubert | + +## Major Contributors + +| | | +|--------------------|-----------------| +| Einaras Bartkus | John Cotter | +| Thomas Chauchefoin | | + +## Contributors and Reviewers + +The OWASP Thick Client Application Security Verification Standard is built by the community, for the community. We thank all contributors who have provided feedback, identified issues, and submitted improvements. + +A full list of contributors is available in the project's [GitHub repository](https://github.com/OWASP/TCASVS/graphs/contributors). diff --git a/5.0/en/0x02-Preface.md b/5.0/en/0x02-Preface.md new file mode 100644 index 0000000..bdbc848 --- /dev/null +++ b/5.0/en/0x02-Preface.md @@ -0,0 +1,48 @@ +# Preface + +## Welcome to TCASVS 5.0.0 + +The OWASP Thick Client Application Security Verification Standard (TCASVS) provides a comprehensive set of security requirements for designing, developing, and testing thick client applications — desktop software, native applications, and other locally-executed programs that operate outside a browser sandbox. + +This standard fills the gap between the [OWASP Application Security Verification Standard (ASVS)](https://github.com/OWASP/ASVS) for web applications and the [Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs). While these standards cover their respective domains well, thick client applications face a distinct combination of threats: they execute on user-controlled hardware, interact with local operating system resources, communicate over untrusted networks, and often run with elevated privileges. + +## What Changed from TASVS + +TCASVS 5.0.0 represents a complete restructuring of the original Thick Application Security Verification Standard (TASVS). Key changes include: + +- **Requirement ID format**: Adopted ASVS numbering (`V{chapter}.{section}.{item}`) replacing the old `TASVS-{CATEGORY}-{group}.{item}` scheme. +- **Level definitions**: Clarified L1/L2/L3 applicability per requirement using a single numeric `Level` column (the lowest applicable level), replacing the old X/blank notation. +- **CWE traceability**: Every requirement now maps to a CWE identifier. +- **Expanded coverage**: From 79 original requirements to over 130 across 6 chapters, with significant gap-fills for build security, memory safety, IPC, and runtime integrity. +- **Chapter restructuring**: Reorganized into chapters that align with ASVS conventions while remaining specific to thick client threats. +- **Version alignment**: Adopted the `5.0.0` version number to mirror OWASP ASVS 5.0.0, signalling that TCASVS shares its format, structure, and publishing pipeline. This co-versioning is a deliberate alignment choice rather than a claim of incremental releases between TASVS 1.0 and this standard. + +## Chapter Structure + +| Chapter | Title | Focus | +|---------|-------|-------| +| V1 | Architecture and Threat Modeling | Threat models, security architecture, attack surface management | +| V2 | Build, Deployment, and Environment Hardening | Supply chain, compiler mitigations, installers, privilege management | +| V3 | Data Storage and Protection | Data classification, file storage, credentials, memory, temp data | +| V4 | Code Quality and Exploit Mitigation | Input validation, memory safety, deserialization, runtime integrity | +| V5 | Cryptography | Algorithms, key management, random values, transport crypto | +| V6 | Network Communication | TLS, service exposure, data leakage, IPC, license validation | + +## Security Verification Levels + +The TCASVS defines three verification levels: + +- **Level 1 (L1)** — Baseline security appropriate for all thick client applications. These requirements address the most common and easily exploitable weaknesses. +- **Level 2 (L2)** — Standard security for applications that handle sensitive data or operate in higher-risk environments. Includes defense-in-depth measures and assumes a more capable adversary. +- **Level 3 (L3)** — Advanced security for applications operating in hostile environments, handling highly sensitive data, or requiring resistance to targeted attacks by skilled adversaries with physical access and reverse engineering capabilities. + +## How to Use This Standard + +The TCASVS can be used as: + +1. **A development guide** — Requirements inform secure design decisions during architecture and implementation. +2. **A verification checklist** — Security testers use requirements as test cases during assessments. +3. **A procurement specification** — Organizations include TCASVS compliance in vendor security requirements. +4. **A maturity benchmark** — Teams assess their current security posture against defined levels and plan improvements. + +Select the appropriate level based on the application's risk profile, then verify all requirements at that level and below are met. diff --git a/5.0/en/0x03-Using-TCASVS.md b/5.0/en/0x03-Using-TCASVS.md new file mode 100644 index 0000000..a335bea --- /dev/null +++ b/5.0/en/0x03-Using-TCASVS.md @@ -0,0 +1,72 @@ +# Using the TCASVS + +## Thick Client Application Security Verification Levels + +The TCASVS defines three security verification levels, with each level increasing in depth and rigour. + +### TCASVS Level 1 — Baseline + +Level 1 is the minimum security standard that all thick client applications should achieve. It focuses on requirements that address the most common and easily exploitable vulnerabilities: hardcoded credentials, missing TLS enforcement, disabled exploit mitigations, and unsafe input handling. + +A Level 1 assessment can typically be performed through a combination of automated scanning, binary analysis, and targeted manual testing. + +### TCASVS Level 2 — Standard + +Level 2 is appropriate for applications that handle sensitive data (PII, financial data, health records), operate in enterprise environments, or face a moderately capable adversary. It adds defense-in-depth requirements including threat modeling, privilege separation, certificate pinning, secure IPC, and runtime integrity checks. + +A Level 2 assessment requires access to source code or debug symbols, architecture documentation, and a thorough security review process. + +### TCASVS Level 3 — Advanced + +Level 3 is reserved for applications operating in hostile environments where the local OS cannot be trusted, where targeted attacks by skilled adversaries are expected, or where compromise would result in significant harm. This includes applications with DRM, anti-cheat, financial trading, critical infrastructure control, or handling classified data. + +Level 3 adds requirements for hardware-backed security, advanced tamper resistance, coverage-guided fuzzing, and cryptographic agility. + +## Applying the Standard + +### For Developers + +Use TCASVS requirements as security acceptance criteria during development: + +1. Identify your target level based on the application's risk profile. +2. Review relevant chapter requirements during design and implementation. +3. Implement requirements as verifiable security controls. +4. Write test cases that validate each requirement is met. + +### For Security Testers + +Use TCASVS as a testing framework: + +1. Scope the assessment to the appropriate level. +2. Use chapter requirements as test cases. +3. Document findings against specific requirement IDs. +4. Report gaps as deviations from the target level. + +### For Organizations + +Use TCASVS as a governance tool: + +1. Define the target level in security policies. +2. Include TCASVS compliance in vendor assessments and procurement. +3. Track compliance over time as a maturity metric. +4. Use gaps between current state and target level to prioritize security investment. + +## Scope + +The TCASVS covers security requirements specific to thick client applications — software that executes locally on user-controlled endpoints. This includes: + +- Desktop applications (Windows, macOS, Linux) +- Native applications with local installation +- Client-server applications where the client runs outside a browser +- Electron, Qt, WPF, WinForms, Swing, and similar framework applications +- Games and multimedia applications +- Enterprise tools and productivity software + +The TCASVS does **not** cover: + +- Server-side API security (use [OWASP ASVS](https://github.com/OWASP/ASVS)) +- Mobile applications (use [OWASP MASVS](https://github.com/OWASP/owasp-masvs)) +- Web applications running in a browser (use OWASP ASVS) +- IoT firmware (specialized standards apply) + +Where thick clients communicate with backend services, the TCASVS covers the client-side implementation of that communication. Server-side security should be verified independently using the ASVS. diff --git a/5.0/en/0x10-V1-Architecture-and-Threat-Modeling.md b/5.0/en/0x10-V1-Architecture-and-Threat-Modeling.md new file mode 100644 index 0000000..d749ce5 --- /dev/null +++ b/5.0/en/0x10-V1-Architecture-and-Threat-Modeling.md @@ -0,0 +1,62 @@ +# V1 Architecture and Threat Modeling + +## Control Objective + +Thick client applications operate in uniquely hostile environments: they execute on hardware controlled by end users, communicate across untrusted networks, interact with local operating system resources, and often run with elevated privileges. Unlike web applications confined to a browser sandbox, thick clients expose a broad and heterogeneous attack surface spanning local filesystems, inter-process communication, kernel interfaces, and network endpoints. Without a structured threat model and deliberate architecture security design, teams cannot systematically identify, prioritize, or mitigate the risks specific to this deployment model. This chapter ensures that thick client applications are designed with security as a first-class architectural concern, that threats are identified and tracked throughout the development lifecycle, and that the full attack surface — including client-specific vectors such as binary tampering, memory manipulation, and privilege escalation — is documented and managed. + +## V1.1 Threat Model Documentation + +A threat model is only useful if it is documented, accessible, and specific enough to drive security decisions. For thick client applications, threat models must account for attack surfaces that do not exist in server-only architectures: local storage, IPC mechanisms, OS-level interactions, and the reality that attackers have full physical access to the client binary. These requirements ensure that threat models exist, are appropriately detailed for the application's risk level, and cover the full scope of thick client deployment. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V1.1.1 | Verify that a threat model exists for the thick client application, identifying at minimum the application's entry points, assets, trust boundaries, and high-level threats relevant to client-side, server-side, network, and local attack surfaces. | 1 | 1053 | TASVS | +| V1.1.2 | Verify that a detailed threat model is maintained for the production application, including data flow diagrams, STRIDE or equivalent threat classification for each component, and risk-rated threat scenarios with documented mitigations. | 2 | 1053 | TASVS | +| V1.1.3 | Verify that the threat model scope explicitly includes all server-side components, third-party dependencies, cloud service integrations (APIs, OIDC providers, file storage), and the communication channels between client and server. | 2 | 1053 | TASVS | +| V1.1.4 | Verify that threat model artifacts are stored in the source code repository alongside the application code, versioned, and reviewable as part of the standard change process. | 1 | 1053 | TASVS | +| V1.1.5 | Verify that the threat model documents all trust boundaries in the application, including boundaries between user-mode and kernel-mode components, between processes of different privilege levels, and between the client application and backend services. | 2 | 501 | New | +| V1.1.6 | Verify that data flow diagrams identify all paths where sensitive data (credentials, tokens, PII, business-critical data) traverses trust boundaries, and document the protection mechanisms applied at each crossing. | 2 | 319 | New | + +## V1.2 Threat Modeling Process + +Creating a threat model once and filing it away provides little ongoing value. Thick client applications evolve rapidly — new features expose new IPC channels, dependency updates introduce new attack surface, and architectural changes shift trust boundaries. These requirements ensure that threat modeling is a living process integrated into the secure development lifecycle, not a one-time compliance exercise. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V1.2.1 | Verify that the threat modeling process encompasses all phases: system modeling (architecture decomposition), automated threat identification (tooling-assisted), manual threat identification (expert review), and threat mitigation planning with assigned owners. | 2 | 1053 | TASVS | +| V1.2.2 | Verify that the threat model is reviewed and updated at defined intervals and upon significant architectural changes, as part of the development team's documented secure development lifecycle (SSDLC). | 2 | 1053 | TASVS | +| V1.2.3 | Verify that the threat model is validated against the implemented application by confirming that documented mitigations are present and effective, and that no undocumented attack surfaces exist. | 3 | 1053 | New | +| V1.2.4 | Verify that threat modeling outputs are used as input for security test planning, with each identified threat having at least one corresponding test case or verification activity. | 2 | 1053 | New | + +## V1.3 Architecture Security Design + +Thick clients face architectural challenges that server-side applications do not: they must manage privilege separation across local processes, isolate plugin subsystems that run untrusted code, secure their own update mechanisms against tampering, and sometimes operate in adversarial environments where the local OS itself cannot be trusted. These requirements ensure that security is designed into the architecture rather than bolted on after deployment. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V1.3.1 | Verify that architecture documentation describes the privilege separation model, including which components run at elevated privilege, what IPC mechanisms connect them, and how the principle of least privilege is applied to each process. | 1 | 250 | New | +| V1.3.2 | Verify that the architecture documents security design principles applied to the thick client, including defense in depth, fail-secure defaults, complete mediation, and economy of mechanism. | 2 | 657 | New | +| V1.3.3 | Verify that the architecture documents how plugin, extension, or scripting subsystems are isolated from the host application, including what APIs are exposed, what permissions are required, and how malicious plugins are prevented from accessing privileged functionality. | 2 | 284 | New | +| V1.3.4 | Verify that the architecture documents the application's update and patching mechanism design, including the trust chain for update verification, rollback capabilities, and how partial or failed updates are handled securely. | 2 | 494 | New | +| V1.3.5 | Verify that the architecture documents how the application handles execution in an adversarial local environment where the OS, other processes, and the user may be hostile (e.g., anti-cheat, DRM, or security-sensitive applications). | 3 | 693 | New | + +## V1.4 Attack Surface Management + +Thick clients expose attack surface across multiple dimensions simultaneously: local filesystem paths, registry keys, named pipes, shared memory, COM objects, listening network ports, outbound connections, and user-facing input vectors. Unlike server applications where the attack surface is primarily network-facing, thick clients must defend against local attackers with debugger access, binary analysis tools, and the ability to inject code into the process. These requirements ensure the full attack surface is identified, documented, and actively managed as the application evolves. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V1.4.1 | Verify that the application's attack surface is documented, including all local interfaces (filesystem paths, registry keys, named pipes, shared memory, COM objects), network interfaces (listening ports, outbound connections), and user-facing input vectors. | 1 | 1059 | New | +| V1.4.2 | Verify that the attack surface documentation identifies which interfaces are exposed to unauthenticated or low-privilege callers, and that each such interface has documented input validation and access control expectations. | 2 | 306 | New | +| V1.4.3 | Verify that the threat model explicitly addresses thick-client-specific attack vectors, including binary reverse engineering, memory tampering, local privilege escalation, DLL/dylib injection, debugger attachment, and inter-process communication abuse. | 1 | 693 | New | +| V1.4.4 | Verify that attack surface changes introduced by new features or dependency updates are assessed and the threat model is updated before deployment to production. | 2 | 1053 | New | + +## References + +- [OWASP Threat Modeling](https://owasp.org/www-community/Threat_Modeling) +- [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) +- [Microsoft STRIDE Threat Model](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats) +- [OWASP Attack Surface Analysis Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html) +- [CWE-1053: Missing Documentation for Design](https://cwe.mitre.org/data/definitions/1053.html) +- [CWE-250: Execution with Unnecessary Privileges](https://cwe.mitre.org/data/definitions/250.html) +- [CWE-494: Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) diff --git a/5.0/en/0x11-V2-Build-Deployment-and-Environment-Hardening.md b/5.0/en/0x11-V2-Build-Deployment-and-Environment-Hardening.md new file mode 100644 index 0000000..dfee8c5 --- /dev/null +++ b/5.0/en/0x11-V2-Build-Deployment-and-Environment-Hardening.md @@ -0,0 +1,68 @@ +# V2 Build, Deployment, and Environment Hardening + +## Control Objective + +Ensure that thick client applications are built, packaged, deployed, and configured in a manner that eliminates unnecessary attack surface and leverages available platform security features. This chapter covers supply chain integrity, compiler-level exploit mitigations, secure installation and update mechanisms, and runtime privilege minimization. + +## V2.1 Build and Supply Chain Security + +This section addresses the integrity of the build pipeline and third-party dependencies, ensuring that production artifacts are trustworthy, minimal, and traceable. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V2.1.1 | Verify that the application build and deployment processes are automated using CI/CD pipelines with integrity-protected build environments, producing reproducible artifacts. | 1 | 1127 | TASVS | +| V2.1.2 | Verify that the application and all dependencies can be re-deployed from automated scripts or restored from backups within a documented recovery timeframe. | 2 | 693 | TASVS | +| V2.1.3 | Verify that production builds exclude all unnecessary features, sample code, documentation, test utilities, and development configurations. | 1 | 489 | TASVS | +| V2.1.4 | Verify that all third-party components are sourced from pre-defined, trusted, and continuously maintained repositories with integrity verification of downloaded artifacts. | 1 | 829 | TASVS | +| V2.1.5 | Verify that a Software Bill of Materials (SBOM) is maintained for all third-party libraries in use, including transitive dependencies, and is updated on each release. | 1 | 1104 | TASVS | +| V2.1.6 | Verify that production builds do not contain debug symbols, verbose error strings, or embedded developer credentials. | 1 | 215 | New | +| V2.1.7 | Verify that released binaries and installers are code-signed with a valid, non-expired certificate, and that the signing key is protected by hardware (HSM or equivalent). | 2 | 494 | New | +| V2.1.8 | Verify that the build system is protected against dependency confusion attacks by pinning dependencies with integrity hashes and using private registry priority for internal packages. | 2 | 427 | New | + +## V2.2 Environment Hardening + +This section covers compiler and OS-level exploit mitigations that must be enabled in production builds to raise the cost of memory corruption exploitation. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V2.2.1 | Verify that compiler and linker flags enable all available exploit mitigations, including stack canaries, stack randomization, and data execution prevention, and that the build fails on unsafe pointer, memory, format string, integer, or string operations. | 1 | 120 | TASVS | +| V2.2.2 | Verify that the application binary enables Address Space Layout Randomization (ASLR) by being compiled as a position-independent executable (PIE) with a high-entropy base address. | 1 | 119 | New | +| V2.2.3 | Verify that Data Execution Prevention (DEP/NX) is enforced for all executable modules, preventing code execution from data segments. | 1 | 119 | New | +| V2.2.4 | Verify that Control Flow Integrity (CFI) protections are enabled where supported by the compiler toolchain, such as Control Flow Guard (CFG) on Windows or CFI on Clang/LLVM. | 2 | 691 | New | +| V2.2.5 | Verify that hardware-assisted exploit mitigations (such as Intel CET shadow stacks or ARM PAC/BTI) are enabled for builds targeting platforms that support them. | 3 | 119 | New | +| V2.2.6 | Verify that the application does not disable or weaken OS-level security features at runtime (e.g., calling SetProcessDEPPolicy to disable DEP, marking memory as RWX without justification). | 2 | 693 | New | + +## V2.3 Installation and Update Security + +This section ensures that installers and auto-update mechanisms cannot be subverted to deliver tampered code or escalate privileges beyond what is necessary. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V2.3.1 | Verify that the installer validates its own integrity before execution (e.g., embedded signature verification or checksum validation from a trusted manifest). | 1 | 354 | New | +| V2.3.2 | Verify that the installer does not create temporary files with insecure permissions in world-writable directories, or that such files are integrity-checked before use. | 1 | 377 | New | +| V2.3.3 | Verify that the application's auto-update mechanism validates cryptographic signatures on update packages before applying them, using a trust anchor independent of the downloaded package. | 1 | 494 | New | +| V2.3.4 | Verify that the auto-update mechanism uses TLS with certificate pinning or equivalent for update downloads, and fails closed if verification fails. | 2 | 295 | New | +| V2.3.5 | Verify that the installer and application use safe DLL search order and do not load libraries from user-writable or uncontrolled directories, preventing DLL sideloading and search-order hijacking. | 1 | 427 | New | +| V2.3.6 | Verify that installer privilege elevation (e.g., UAC prompts on Windows) is limited to the minimum operations that require elevated privileges, and that elevated child processes are not exposed to untrusted input. | 2 | 250 | New | + +## V2.4 Privilege and Permission Management + +This section addresses runtime privilege minimization, process isolation, and proper access control on filesystem and IPC objects created by the application. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V2.4.1 | Verify that the application runs with the minimum privileges required for its functionality, and that elevated components expose only the minimum necessary IPC interface surface. | 1 | 250 | TASVS | +| V2.4.2 | Verify that the application satisfies the "Rule of 2": it does not simultaneously process untrustworthy input, use a memory-unsafe language, and run with elevated privileges or without a sandbox. | 1 | 250 | TASVS | +| V2.4.3 | Verify that filesystem permissions are correctly restricted on all directories and files created, modified, or accessed during installation and at runtime, preventing unauthorized read, write, or execute access by lower-privileged users. | 1 | 732 | TASVS | +| V2.4.4 | Verify that Windows services or system daemons used by the application run under dedicated service accounts with minimal privileges, not as LocalSystem, root, or equivalent unless explicitly justified and documented. | 2 | 250 | New | +| V2.4.5 | Verify that configuration files, registry keys, and local databases used by the application are protected with restrictive ACLs preventing modification by non-administrative users. | 1 | 732 | New | +| V2.4.6 | Verify that the application implements sandboxing or process isolation for components that handle untrusted input (e.g., file parsers, protocol handlers, plugin hosts), limiting access to the filesystem, network, and system APIs. | 2 | 265 | New | +| V2.4.7 | Verify that named pipes, shared memory segments, and other OS IPC objects created by the application use restrictive security descriptors that prevent connection or modification by unauthorized processes. | 2 | 732 | New | + +## References + +- [OWASP ASVS 5.0.0](https://github.com/OWASP/ASVS) +- [CWE/SANS Top 25](https://cwe.mitre.org/top25/) +- [Microsoft Security Development Lifecycle](https://www.microsoft.com/en-us/securityengineering/sdl) +- [NIST SP 800-218 - Secure Software Development Framework](https://csrc.nist.gov/publications/detail/sp/800-218/final) +- [SLSA Supply Chain Levels for Software Artifacts](https://slsa.dev/) diff --git a/5.0/en/0x12-V3-Data-Storage-and-Protection.md b/5.0/en/0x12-V3-Data-Storage-and-Protection.md new file mode 100644 index 0000000..95e653e --- /dev/null +++ b/5.0/en/0x12-V3-Data-Storage-and-Protection.md @@ -0,0 +1,75 @@ +# V3 Data Storage and Protection + +## Control Objective + +Thick client applications operate in environments where the local filesystem, process memory, OS registries, and inter-process channels are all potential attack surfaces. Unlike server-side applications running in controlled data centres, thick clients execute on endpoints that may be shared between users, physically accessible to adversaries, or subject to forensic recovery. Data stored locally — whether in configuration files, databases, memory, or temporary files — is exposed to extraction by malware, co-resident applications, privileged users, and offline analysis of disk images. + +Ensure that the thick client correctly classifies sensitive data, protects it at rest using platform-provided secure storage mechanisms, minimizes the window of exposure in process memory, and performs thorough cleanup of residual data. The controls in this chapter address the full local data lifecycle: classification, file and configuration storage, credential management, memory protection, and temporary data hygiene. + +## V3.1 Data Classification and Policy + +Effective data protection begins with understanding what data the application handles and how sensitive it is. Without explicit classification and retention policies, developers cannot make informed decisions about which storage mechanisms and protections are appropriate. This section ensures that sensitive data is identified, categorized, and subject to defined lifecycle management — preventing accumulation of unprotected data that outlives its purpose. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V3.1.1 | Verify that all sensitive data created, processed, or stored by the application has been identified, classified into protection levels, and that documented protection requirements exist for each level. | 2 | 922 | TASVS | +| V3.1.2 | Verify that a data retention policy is defined and enforced, ensuring that sensitive data is automatically deleted or anonymized when no longer required for its stated purpose. | 2 | 922 | New | + +## V3.2 Sensitive Data in Files and Configuration + +Thick clients store data across numerous local surfaces: application binaries, configuration files, OS registries, property lists, log files, and embedded databases. Each of these is readable by local users, backup tools, and forensic analysis unless explicitly protected. Hardcoded secrets are trivially extractable through static analysis tools. This section ensures that no sensitive data is exposed in plaintext through any local file or configuration store. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V3.2.1 | Verify that binaries, configuration files, and application data files do not contain plaintext credentials, connection strings, API keys, or other secrets. | 1 | 798 | TASVS | +| V3.2.2 | Verify that registry entries, property lists (plists), and other OS-level configuration stores do not contain plaintext credentials, connection strings, API keys, or other secrets. | 1 | 798 | TASVS | +| V3.2.3 | Verify that application logs do not capture or persist sensitive data, including PII, credentials, session tokens, or connection strings used for internal or external resources. | 1 | 532 | TASVS | +| V3.2.4 | Verify that sensitive data embedded in application binaries (such as hardcoded keys, certificates, or configuration) is not discoverable through trivial static analysis or string extraction. | 1 | 798 | TASVS | +| V3.2.5 | Verify that local databases (SQLite, LevelDB, Realm, etc.) containing sensitive data are stored in protected directories with restrictive filesystem permissions and, where supported, use database-level encryption. | 1 | 311 | New | +| V3.2.6 | Verify that application backup or export functionality excludes or encrypts sensitive data, and that backup files are stored with restrictive permissions. | 2 | 530 | New | + +## V3.3 Credential and Secret Storage + +Credentials, tokens, and cryptographic keys require stronger protection than general application data. Thick clients must leverage OS-provided secure storage mechanisms rather than implementing custom solutions that are likely to be weaker and less audited. On multi-user systems, secrets stored insecurely are accessible to other user accounts or malware running at the same privilege level. This section ensures that all authentication material and sensitive keys are stored using platform security primitives. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V3.3.1 | Verify that authentication tokens and session identifiers are stored using OS-provided secure storage mechanisms (e.g., Windows Credential Manager, macOS Keychain, Linux Secret Service) and are not accessible to other applications or lower-privileged users. | 1 | 522 | TASVS | +| V3.3.2 | Verify that regulated private, health, or financial data is stored encrypted at rest using approved algorithms and key management practices, compliant with applicable data protection regulations (e.g., GDPR, HIPAA, PCI DSS). | 1 | 311 | TASVS | +| V3.3.3 | Verify that the application uses OS-provided credential storage APIs (e.g., Windows DPAPI, macOS Keychain, Linux libsecret) for persisting secrets, rather than custom or plaintext storage mechanisms. | 1 | 522 | New | +| V3.3.4 | Verify that cryptographic keys stored locally are protected by hardware-backed keystores where available (e.g., TPM, Secure Enclave, platform keystore APIs) and are not exportable in plaintext. | 3 | 321 | New | + +## V3.4 Memory Protection + +Process memory is a high-value target for attackers with local access. Sensitive data that remains in memory after use can be recovered through memory dumps, debugger attachment, swap file analysis, or crash dump collection. On multi-user workstations, clipboard contents are shared across all applications. This section ensures that the application minimizes the time sensitive data spends in memory and prevents leakage through memory-adjacent channels such as swap, clipboard, and crash dumps. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V3.4.1 | Verify that the application does not retain sensitive data in process memory longer than necessary, and that memory containing secrets is explicitly zeroed or overwritten immediately after use. | 1 | 316 | TASVS | +| V3.4.2 | Verify that the application marks memory pages containing sensitive data as non-pageable (e.g., VirtualLock on Windows, mlock on Linux) to prevent secrets from being written to swap/pagefile. | 2 | 316 | New | +| V3.4.3 | Verify that the application prevents sensitive data from being exposed through clipboard operations, either by clearing the clipboard after a short timeout or by preventing copy operations on sensitive fields. | 1 | 200 | New | +| V3.4.4 | Verify that crash dumps and core files generated by the application do not contain sensitive data, or that crash dump generation is configured to exclude sensitive memory regions. | 2 | 215 | New | + +## V3.5 Temporary and Residual Data + +Thick clients frequently create temporary files for caching, inter-process data exchange, or intermediate processing. These files persist on disk after the process exits and can be recovered by other users, malware, or forensic tools. Shared system temp directories are particularly dangerous as they are writable and readable by all local users, enabling symlink attacks and data theft. This section ensures that the application manages temporary data securely and leaves no sensitive residuals after logout or uninstall. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V3.5.1 | Verify that the application removes temporary files containing sensitive data immediately after use, using secure deletion where the OS supports it. | 1 | 459 | New | +| V3.5.2 | Verify that temporary files are created in application-specific directories with restrictive permissions, not in shared system temp directories accessible to other users. | 1 | 377 | New | +| V3.5.3 | Verify that the application performs secure cleanup of all locally stored sensitive data (including cached credentials, tokens, and session state) upon user logout or application uninstall. | 1 | 459 | New | +| V3.5.4 | Verify that inter-process communication of sensitive data between application components uses authenticated, encrypted channels rather than world-readable shared files or environment variables. | 2 | 319 | New | + +## References + +- [OWASP Credential Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Storage_Cheat_Sheet.html) +- [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) +- [CWE-922: Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) +- [CWE-798: Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) +- [CWE-316: Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) +- [CWE-522: Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) +- [CWE-311: Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) +- [CWE-459: Incomplete Cleanup](https://cwe.mitre.org/data/definitions/459.html) +- [Microsoft DPAPI Documentation](https://learn.microsoft.com/en-us/windows/win32/seccng/cng-dpapi) +- [Apple Keychain Services](https://developer.apple.com/documentation/security/keychain_services) diff --git a/5.0/en/0x13-V4-Code-Quality-and-Exploit-Mitigation.md b/5.0/en/0x13-V4-Code-Quality-and-Exploit-Mitigation.md new file mode 100644 index 0000000..dd361b1 --- /dev/null +++ b/5.0/en/0x13-V4-Code-Quality-and-Exploit-Mitigation.md @@ -0,0 +1,98 @@ +# V4 Code Quality and Exploit Mitigation + +## Control Objective + +Thick client applications are uniquely exposed to code-level attacks because they execute locally on user-controlled hardware, often include unmanaged native code, and process untrusted input from local filesystems, IPC channels, clipboard data, and network sources simultaneously. Unlike server-side applications protected by network perimeters and managed runtimes, thick clients must defend against attackers who can inspect binaries, manipulate memory, inject malformed files, and tamper with the running process. This chapter ensures that thick client code is hardened against injection, memory corruption, unsafe deserialization, and runtime tampering — and that code quality practices are sufficient to prevent exploitable defects from reaching production. Server-side API and service-level testing is deferred to the OWASP ASVS; this chapter focuses exclusively on the client binary, its local processing logic, and the interaction surfaces unique to thick client deployment. + +## V4.1 Input Validation and Injection Prevention + +Thick clients consume input from far more sources than web applications: file parsers, IPC channels, named pipes, shared memory, clipboard, drag-and-drop, COM/D-Bus interfaces, command-line arguments, and custom URL scheme handlers all feed data into the application. Each of these paths represents a potential injection vector if input is not rigorously validated before processing. These requirements ensure that all input — regardless of source — is validated, sanitized, and constrained before it reaches application logic. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V4.1.1 | Verify that untrusted data passed through macro engines, templating systems, or expression evaluators is protected against injection by using parameterization, sandboxed execution, or context-aware escaping. | 1 | 94 | TASVS | +| V4.1.2 | Verify that the application protects against OS command injection by avoiding shell invocations with user-controlled input, or where unavoidable, by using parameterized APIs and strict allowlist validation of arguments. | 1 | 78 | TASVS | +| V4.1.3 | Verify that all unstructured input is validated against an allowlist of permitted characters and constrained to a maximum length appropriate for the field's purpose before further processing. | 1 | 20 | TASVS | +| V4.1.4 | Verify that all process spawning and external program execution uses validated, fully-qualified paths and that all arguments are sanitized or parameterized to prevent argument injection and arbitrary command execution. | 1 | 78 | TASVS | +| V4.1.5 | Verify that user-submitted filename metadata is never used directly in filesystem operations, and that path traversal sequences, null bytes, and archive-relative paths (ZipSlip) are rejected or neutralized before file extraction or access. | 1 | 22 | TASVS | +| V4.1.6 | Verify that files imported or opened by the application are validated and parsed safely, ensuring that malformed, oversized, or malicious file content cannot trigger code execution, denial of service, or memory corruption in the thick client. | 1 | 434 | TASVS | +| V4.1.7 | Verify that the application validates and sanitizes all data received through inter-process communication channels (named pipes, shared memory, COM/D-Bus interfaces, clipboard) before processing, with the same rigour applied to network input. | 1 | 20 | New | +| V4.1.8 | Verify that the application does not construct or evaluate dynamic code (e.g., eval(), dlopen() with user paths, LoadLibrary() with user-controlled names, JIT compilation of user input) unless strictly required, and that any such usage is sandboxed and input-validated. | 1 | 94 | New | + +## V4.2 Memory Safety and Unmanaged Code + +Many thick client applications include native code components — whether written directly in C/C++, accessed through FFI bindings, or inherited from legacy libraries. Memory corruption vulnerabilities in these components represent the highest-severity risk class for thick clients because they enable arbitrary code execution with the application's privileges. These requirements ensure that unmanaged code follows memory-safe patterns and that compiler/runtime mitigations are in place to increase the cost of exploitation. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V4.2.1 | Verify that the application uses memory-safe string operations, bounds-checked memory copy functions, and safe pointer arithmetic to prevent stack-based, buffer-based, and heap-based overflow vulnerabilities. | 1 | 120 | TASVS | +| V4.2.2 | Verify that format string functions do not accept user-controlled format specifiers, and that all format strings are compile-time constants or are validated against a strict allowlist. | 1 | 134 | TASVS | +| V4.2.3 | Verify that sign, range, and input validation techniques are applied to all arithmetic operations to prevent integer overflows, underflows, and truncation that could lead to memory corruption or logic errors. | 1 | 190 | TASVS | +| V4.2.4 | Verify that in unmanaged or native code, dynamically allocated memory is freed exactly once, that pointers to freed memory are immediately nullified, and that use-after-free, double-free, and dangling pointer conditions are prevented through consistent ownership semantics. | 1 | 416 | TASVS | +| V4.2.5 | Verify that the application uses safe file operation patterns to prevent symlink and hard link attacks, including verifying the final resolved path before access and using exclusive file creation flags where supported by the OS. | 1 | 59 | TASVS | +| V4.2.6 | Verify that stack buffer overflow protections are validated at the binary level (e.g., presence of /GS cookies, _FORTIFY_SOURCE, -fstack-protector-strong) for all compiled modules, complementing V2.2.1 build-time requirements with runtime verification. | 1 | 121 | New | +| V4.2.7 | Verify that heap allocator hardening features are enabled where available (e.g., Windows Segment Heap, glibc heap checking, guard pages between allocations) to increase the difficulty of heap exploitation. | 2 | 122 | New | + +## V4.3 Deserialization and Data Interchange + +Thick clients frequently consume serialized data from multiple sources: configuration files, saved state, IPC messages, network responses, and plugin data. Unlike server applications that primarily deserialize HTTP request bodies, thick clients may process serialized objects from local storage, clipboard, drag-and-drop, or named pipes — all of which may be attacker-controlled. Unsafe deserialization in these contexts can lead to remote code execution, privilege escalation, or arbitrary object instantiation. These requirements ensure that all deserialization is performed safely regardless of data source. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V4.3.1 | Verify that XML parsers are configured to use the most restrictive settings available, including disabling external entity resolution (XXE), DTD processing, XInclude, and XSLT where not required. | 1 | 611 | TASVS | +| V4.3.2 | Verify that serialized objects transmitted or stored include integrity verification (e.g., HMAC or digital signature) to detect tampering, and that the integrity check is validated before deserialization. | 1 | 502 | TASVS | +| V4.3.3 | Verify that deserialization of untrusted data is avoided where possible, and where required, uses safe deserialization mechanisms such as allowlists of permitted types, restricted class resolution, and isolated execution contexts. | 1 | 502 | TASVS | +| V4.3.4 | Verify that the application does not deserialize data from unauthenticated or integrity-unverified IPC sources, and that all inter-component serialized data uses a well-defined schema with strict type enforcement. | 2 | 502 | New | + +## V4.4 Runtime Integrity and Tamper Resistance + +Because thick clients run on user-controlled hardware, adversaries can attach debuggers, patch binaries, hook API calls, and modify application memory at runtime. While no client-side protection is unbreakable, layered integrity checks significantly raise the cost of tampering and detect unsophisticated attacks. These requirements are particularly relevant for applications handling sensitive data, implementing licensing controls, or operating in adversarial environments where client integrity directly affects security decisions. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V4.4.1 | Verify that the application validates the integrity of its own executable files, libraries, and critical data files at load time using cryptographic hashes or signatures, and fails safely if tampering is detected. | 2 | 354 | TASVS | +| V4.4.2 | Verify that the application performs runtime integrity self-checks (e.g., code section checksums, anti-debugging detection, hook detection) and responds to detected tampering with appropriate countermeasures such as graceful shutdown or reduced functionality. | 3 | 693 | TASVS | +| V4.4.3 | Verify that the application detects and responds to debugger attachment in production builds by restricting functionality or terminating, and that anti-debugging measures cannot be trivially bypassed by patching a single check. | 3 | 693 | New | + +## V4.5 Secure Interaction and Attack Surface Reduction + +Thick clients interact with users, the operating system, and other applications through rich interfaces that web applications do not expose: custom URL scheme handlers, protocol handlers, drag-and-drop targets, clipboard monitors, and plugin ecosystems. Each interaction surface represents both a usability feature and a potential attack vector. These requirements ensure that interaction surfaces cannot be abused to trick users, escalate privileges, or bypass security controls. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V4.5.1 | Verify that the application does not employ deceptive user interface patterns (dark patterns) that mislead users into granting excessive permissions, sharing sensitive data, or bypassing security warnings. | 1 | 451 | TASVS | +| V4.5.2 | Verify that application workflows do not violate established security principles, such as requiring users to disable security features, store credentials insecurely, or bypass certificate warnings to complete normal operations. | 1 | 657 | TASVS | +| V4.5.3 | Verify that custom URL schemes and protocol handlers registered by the application validate all parameters before processing, cannot trigger dangerous actions (e.g., file deletion, code execution, privilege escalation) without explicit user confirmation, and reject unexpected or malformed URIs. | 1 | 939 | TASVS | +| V4.5.4 | Verify that the application restricts or sandboxes plugin and extension loading to prevent untrusted third-party plugins from accessing sensitive application data, elevated privileges, or bypassing security controls. | 2 | 829 | New | +| V4.5.5 | Verify that drag-and-drop, paste-from-clipboard, and other user-initiated data import paths apply the same input validation and sanitization as file open operations. | 1 | 20 | New | + +## V4.6 Code Quality Assurance + +Exploitable vulnerabilities in thick clients frequently originate from preventable code quality failures: unhandled exceptions that leak state, missing error checks on system calls, dead code that contains deprecated insecure patterns, and insufficient testing of input-processing routines. These requirements ensure that the development and release process includes systematic checks — static analysis, fuzzing, and secure coding validation — that catch exploitable defects before they ship in production binaries. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V4.6.1 | Verify that the application handles all exceptions and errors securely without exposing sensitive system information, stack traces, or internal paths to users, and that unhandled exceptions cannot leave the application in an insecure state. | 1 | 209 | TASVS | +| V4.6.2 | Verify that binary static analysis has been performed on the compiled application to confirm the absence of known vulnerable coding patterns, and that identified findings are triaged and remediated according to severity. | 2 | 1078 | TASVS | +| V4.6.3 | Verify that Static Application Security Testing (SAST) is integrated into the development pipeline and executed against every release candidate, with blocking thresholds for critical and high-severity findings. | 1 | 1078 | TASVS | +| V4.6.4 | Verify that documented secure coding policies and security test cases exist, are maintained alongside the codebase, and are validated as part of the release process. | 2 | 657 | TASVS | +| V4.6.5 | Verify that dead code, unreachable code paths, and unused dependencies are identified and removed to minimize the application's attack surface. | 2 | 561 | TASVS | +| V4.6.6 | Verify that randomized input fuzzing (mutation-based) has been performed against all file parsers, protocol handlers, and IPC interfaces exposed by the application, and that identified crashes are triaged for exploitability. | 2 | 120 | TASVS | +| V4.6.7 | Verify that coverage-guided fuzzing (generation-based or feedback-driven) has been performed to maximize code path coverage of input parsing and data processing routines, with crash analysis and remediation of all exploitable findings. | 3 | 120 | TASVS | +| V4.6.8 | Verify that the application implements defensive error handling for all native API calls, including checking return values from memory allocation, file operations, and system calls, and failing safely when unexpected errors occur. | 1 | 252 | New | + +## References + +- [OWASP Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) +- [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) +- [OWASP XML External Entity Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) +- [CWE-20: Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) +- [CWE-78: OS Command Injection](https://cwe.mitre.org/data/definitions/78.html) +- [CWE-94: Improper Control of Generation of Code (Code Injection)](https://cwe.mitre.org/data/definitions/94.html) +- [CWE-120: Buffer Copy without Checking Size of Input](https://cwe.mitre.org/data/definitions/120.html) +- [CWE-134: Use of Externally-Controlled Format String](https://cwe.mitre.org/data/definitions/134.html) +- [CWE-190: Integer Overflow or Wraparound](https://cwe.mitre.org/data/definitions/190.html) +- [CWE-416: Use After Free](https://cwe.mitre.org/data/definitions/416.html) +- [CWE-502: Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) +- [CWE-611: Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) +- [CWE-693: Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) diff --git a/5.0/en/0x14-V5-Cryptography.md b/5.0/en/0x14-V5-Cryptography.md new file mode 100644 index 0000000..4f20479 --- /dev/null +++ b/5.0/en/0x14-V5-Cryptography.md @@ -0,0 +1,77 @@ +# V5 Cryptography + +## Control Objective + +Ensure that the thick client application implements cryptography in accordance with current industry best practices. This includes using approved algorithms and protocols, managing keys securely throughout their lifecycle, generating cryptographically strong random values, and establishing secure transport channels. Cryptographic controls must protect data confidentiality, integrity, and authenticity both at rest and in transit, while remaining agile enough to accommodate algorithm deprecation and key rotation without requiring full application rebuilds. + +## V5.1 Cryptographic Policy and Inventory + +A documented cryptographic policy and complete inventory provide the foundation for managing cryptographic risk in thick client applications. Without visibility into which algorithms, keys, and certificates are in use, organizations cannot assess exposure when weaknesses are discovered. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V5.1.1 | Verify that there is a documented policy for cryptographic key management, including key generation, distribution, storage, rotation, and revocation, following a standard such as NIST SP 800-57. | 2 | 320 | New | +| V5.1.2 | Verify that a cryptographic inventory is maintained, covering all keys, algorithms, and certificates used by the thick client, including those embedded in the binary or configuration files. | 3 | 311 | New | + +## V5.2 Secure Cryptographic Implementation + +Correct implementation of cryptographic primitives is as important as algorithm selection. Failure modes, library choices, and architectural flexibility determine whether cryptography provides real protection or a false sense of security. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V5.2.1 | Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities such as Padding Oracle attacks. | 2 | 310 | TASVS | +| V5.2.2 | Verify that industry-validated or government-approved cryptographic algorithms, modes, and libraries are used instead of custom-coded cryptography. | 2 | 327 | TASVS | +| V5.2.3 | Verify that the application is designed with crypto agility such that algorithms, key lengths, and modes can be reconfigured or upgraded without requiring a full application rebuild. | 2 | 327 | New | + +## V5.3 Encryption Algorithms and Protocols + +Thick clients must avoid deprecated cryptographic primitives and enforce minimum security strengths. Algorithm and mode selection directly determines the effective security of data protection mechanisms. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V5.3.1 | Verify that the thick client does not use cryptographic protocols or algorithms that are widely considered deprecated or insecure (e.g., DES, 3DES, RC4, MD5, SHA-1 for signing). | 1 | 327 | TASVS | +| V5.3.2 | Verify that only approved ciphers and authenticated encryption modes (e.g., AES-GCM, ChaCha20-Poly1305) are used, and insecure block modes (e.g., ECB) or weak padding schemes (e.g., PKCS#1 v1.5) are not used. | 1 | 327 | New | +| V5.3.3 | Verify that all cryptographic primitives utilize a minimum of 128 bits of security based on the algorithm, key size, and configuration. | 2 | 326 | New | + +## V5.4 Random Values + +Thick clients frequently generate random values for session tokens, nonces, initialization vectors, and key material. Weak or predictable randomness undermines the security of all dependent cryptographic operations. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V5.4.1 | Verify that all random numbers and strings intended to be non-guessable are generated using a cryptographically secure pseudo-random number generator (CSPRNG) with at least 128 bits of entropy. | 2 | 338 | TASVS | +| V5.4.2 | Verify that the random number generation mechanism works securely under heavy demand and does not degrade to predictable output when entropy is low. | 3 | 332 | New | + +## V5.5 Key Management and Storage + +Cryptographic keys require protection throughout their lifecycle. Thick clients present unique challenges because keys may be embedded in binaries, stored on user-controlled filesystems, or held in process memory accessible to local attackers. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V5.5.1 | Verify that the thick client does not reuse the same cryptographic key for multiple purposes (e.g., encryption and authentication). | 2 | 323 | TASVS | +| V5.5.2 | Verify that the thick client does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption, and that keys are not extractable from the binary. | 1 | 321 | TASVS | +| V5.5.3 | Verify that cryptographic keys stored locally are protected using platform-provided secure storage mechanisms (e.g., Windows DPAPI, macOS Keychain, Linux kernel keyring) rather than plaintext files or application-level obfuscation. | 1 | 312 | New | +| V5.5.4 | Verify that cryptographic keys are protected in memory during runtime, using techniques such as zeroing after use, avoiding swap/page-out of key material, or leveraging hardware-backed key isolation where available. | 3 | 316 | New | + +## V5.6 Transport Cryptography + +Thick clients communicate with backend services over networks that may be hostile. Transport layer protections must ensure confidentiality, integrity, and server authenticity while preventing downgrade attacks and certificate validation bypasses. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V5.6.1 | Verify that TLS settings are in line with current best practices, including TLS 1.2+ with secure cipher suites and Perfect Forward Secrecy enabled. | 1 | 326 | TASVS | +| V5.6.2 | Verify that the thick client validates server certificates correctly, including checking certificate chains, revocation status, and hostname matching, and does not silently bypass certificate errors. | 1 | 295 | New | +| V5.6.3 | Verify that certificate pinning is implemented for connections to known backend services, with a documented update mechanism for pin rotation. | 2 | 295 | New | +| V5.6.4 | Verify that code signing is used for application binaries and updates, and that the thick client validates signatures before executing downloaded code or applying updates. | 2 | 494 | New | + +## References + +For more information, see: + +* [NIST SP 800-57 — Recommendation for Key Management](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final) +* [NIST SP 800-131A — Transitioning the Use of Cryptographic Algorithms and Key Lengths](https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final) +* [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +* [OWASP Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) +* [OWASP Key Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html) +* [CWE-310 — Cryptographic Issues](https://cwe.mitre.org/data/definitions/310.html) +* [CWE-327 — Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) diff --git a/5.0/en/0x15-V6-Network-Communication.md b/5.0/en/0x15-V6-Network-Communication.md new file mode 100644 index 0000000..68eae08 --- /dev/null +++ b/5.0/en/0x15-V6-Network-Communication.md @@ -0,0 +1,65 @@ +# V6 Network Communication Security + +## Control Objective + +Thick client applications frequently communicate over networks with backend services, license servers, update mechanisms, and third-party APIs. Unlike web applications where the browser enforces transport security policies, thick clients must implement and enforce their own network security controls, making them susceptible to interception, downgrade attacks, and unintended service exposure. + +Ensure that all network communication channels used by the thick client are protected against eavesdropping, tampering, and unauthorized access. This includes enforcing modern transport encryption, minimizing network attack surface, preventing data leakage through side channels, securing local inter-process communication, and protecting license validation flows from manipulation. + +## V6.1 Transport Layer Security + +Thick clients often manage their own TLS stack or rely on platform libraries that may be misconfigured. Attackers with network access can exploit missing or weak TLS enforcement to intercept credentials, session tokens, and business-critical data. This section ensures all network-facing channels enforce modern authenticated encryption without fallback to insecure transports. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V6.1.1 | Verify that all network communication channels used by the thick client enforce TLS consistently, with no fallback to unencrypted transport. | 1 | 319 | TASVS | +| V6.1.2 | Verify that all connections to backend services, update servers, telemetry endpoints, and third-party APIs enforce TLS 1.2 or higher with no protocol downgrade possible. | 1 | 757 | New | +| V6.1.3 | Verify that custom or proprietary protocols used by the thick client are wrapped in TLS or provide equivalent authenticated encryption for data in transit. | 2 | 319 | New | + +## V6.2 Network Service Exposure + +Thick clients may inadvertently expose debugging interfaces, plugin APIs, or management ports on local or external network interfaces. Attackers on the same network or local machine can discover and exploit these exposed services for privilege escalation or remote code execution. This section ensures the application minimizes its network attack surface. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V6.2.1 | Verify that the thick client does not expose network services (e.g., debugging interfaces, management ports) on any interface, including localhost, unless explicitly required and authenticated. | 1 | 489 | TASVS | +| V6.2.2 | Verify that the application does not bind listener sockets to all interfaces (0.0.0.0/::) when only local communication is required. | 1 | 668 | New | +| V6.2.3 | Verify that any network services intentionally exposed by the thick client require authentication before accepting commands or data. | 2 | 306 | New | + +## V6.3 Network Data Leakage Prevention + +Thick clients may leak sensitive information through unencrypted channels, URL parameters, HTTP headers, or verbose error messages visible on the wire. Unlike server-side applications, thick clients often lack centralized egress controls, making it critical to validate that no sensitive data escapes through network side channels. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V6.3.1 | Verify that sensitive tokens, keys, and credentials are not transmitted in plaintext or weakly encoded forms susceptible to interception by man-in-the-middle attacks. | 1 | 319 | TASVS | +| V6.3.2 | Verify that sensitive data (credentials, tokens, PII) is not leaked through URL parameters, HTTP referrer headers, or unencrypted DNS queries. | 1 | 598 | New | +| V6.3.3 | Verify that network traffic does not expose unnecessary metadata or debug information (e.g., internal hostnames, stack traces, software version strings) in cleartext. | 2 | 200 | New | + +## V6.4 Inter-Process and Local Network Communication + +Thick clients commonly use IPC mechanisms such as named pipes, Unix sockets, shared memory, or loopback TCP connections to coordinate between components or plugins. Malicious local processes can inject commands or tamper with data flowing through unprotected IPC channels, particularly in multi-user or shared workstation environments. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V6.4.1 | Verify that inter-process communication channels (named pipes, Unix sockets, shared memory, local TCP) implement authentication to prevent unauthorized local processes from connecting. | 2 | 420 | New | +| V6.4.2 | Verify that data exchanged over local IPC channels is integrity-protected to prevent tampering by other local processes running at the same privilege level. | 3 | 345 | New | + +## V6.5 License Server Communication + +Many thick clients depend on network-based license validation to enforce access controls and feature gating. Attackers commonly target license server communications to bypass restrictions through replay attacks, response manipulation, or exploiting offline fallback behavior. This section ensures license-related network flows are resistant to tampering and bypass. + +| # | Description | Level | CWE | Source | +|---|-------------|:-----:|-----|--------| +| V6.5.1 | Verify that license validation communications are performed over authenticated, encrypted channels and include replay protection (e.g., nonces or timestamps). | 1 | 294 | New | +| V6.5.2 | Verify that the thick client handles license server unavailability securely without exposing premium functionality or bypassing access controls during the outage. | 2 | 636 | New | + +## References + +- [OWASP Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) +- [CWE-319: Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) +- [CWE-306: Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) +- [CWE-294: Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) +- [CWE-420: Unprotected Alternate Channel](https://cwe.mitre.org/data/definitions/420.html) +- [NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of TLS Implementations](https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final) +- [NIST SP 800-77 Rev. 1: Guide to IPsec VPNs](https://csrc.nist.gov/publications/detail/sp/800-77/rev-1/final) diff --git a/5.0/en/0x90-Appendix-A_Glossary.md b/5.0/en/0x90-Appendix-A_Glossary.md new file mode 100644 index 0000000..70930a8 --- /dev/null +++ b/5.0/en/0x90-Appendix-A_Glossary.md @@ -0,0 +1,27 @@ +# Appendix A: Glossary + +| Term | Definition | +|------|-----------| +| ASLR | Address Space Layout Randomization — a memory protection technique that randomizes the locations of key data areas in a process. | +| CFI | Control Flow Integrity — a security mechanism that restricts the set of valid call targets at each indirect branch. | +| COM | Component Object Model — a Microsoft binary-interface standard for software componentry and interprocess communication. | +| CSPRNG | Cryptographically Secure Pseudo-Random Number Generator — a PRNG suitable for use in cryptographic contexts. | +| D-Bus | Desktop Bus — a message bus system for inter-process communication on Linux/Unix systems. | +| DEP | Data Execution Prevention — a system-level memory protection feature that marks memory regions as non-executable. | +| DLL | Dynamic Link Library — a shared library mechanism on Windows used to share code and data between programs. | +| DPAPI | Data Protection API — a Windows API for encrypting data using credentials derived from the user's logon credentials. | +| FFI | Foreign Function Interface — a mechanism allowing code in one language to call code written in another language. | +| HSM | Hardware Security Module — a physical computing device that safeguards and manages cryptographic keys. | +| IPC | Inter-Process Communication — mechanisms for processes to communicate and synchronize with each other. | +| L1 | TCASVS Level 1 — Baseline security requirements applicable to all thick client applications. | +| L2 | TCASVS Level 2 — Standard security for applications handling sensitive data. | +| L3 | TCASVS Level 3 — Advanced security for applications in hostile environments. | +| NX | No-Execute — a hardware-level feature marking memory pages as non-executable. | +| PIE | Position-Independent Executable — an executable binary that can be loaded at any memory address. | +| SBOM | Software Bill of Materials — a formal record of the components and dependencies in a software product. | +| SSDLC | Secure Software Development Lifecycle — a structured approach to building security into every phase of software development. | +| STRIDE | Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — a threat classification model. | +| Thick Client | A locally-installed application that performs significant processing on the user's device, as opposed to thin clients that rely on server-side processing. | +| TLS | Transport Layer Security — a cryptographic protocol for securing communications over a network. | +| TPM | Trusted Platform Module — a hardware chip that provides cryptographic functions and secure key storage. | +| UAC | User Account Control — a Windows security feature that limits application software to standard user privileges. | diff --git a/5.0/en/0x91-Appendix-B_References.md b/5.0/en/0x91-Appendix-B_References.md new file mode 100644 index 0000000..6f6db96 --- /dev/null +++ b/5.0/en/0x91-Appendix-B_References.md @@ -0,0 +1,51 @@ +# Appendix B: References + +## OWASP Projects + +1. OWASP Application Security Verification Standard (ASVS): +2. OWASP Mobile Application Security Verification Standard (MASVS): +3. OWASP Software Assurance Maturity Model (SAMM): +4. OWASP Threat Modeling: +5. OWASP Cheat Sheet Series: + +## Standards and Frameworks + +1. NIST SP 800-57 — Key Management: +2. NIST SP 800-131A — Cryptographic Algorithm Transitions: +3. NIST SP 800-218 — Secure Software Development Framework: +4. NIST SP 800-52 — TLS Guidelines: +5. SLSA — Supply Chain Levels for Software Artifacts: +6. CWE/SANS Top 25: + +## Platform Security References + +1. Microsoft Security Development Lifecycle: +2. Microsoft DPAPI Documentation: +3. Apple Keychain Services: +4. Linux Kernel Keyring: + +## Relevant CWE Categories + +| CWE ID | Title | +|--------|-------| +| CWE-20 | Improper Input Validation | +| CWE-78 | OS Command Injection | +| CWE-94 | Code Injection | +| CWE-120 | Buffer Copy without Checking Size of Input | +| CWE-190 | Integer Overflow or Wraparound | +| CWE-250 | Execution with Unnecessary Privileges | +| CWE-311 | Missing Encryption of Sensitive Data | +| CWE-316 | Cleartext Storage of Sensitive Information in Memory | +| CWE-319 | Cleartext Transmission of Sensitive Information | +| CWE-321 | Use of Hard-coded Cryptographic Key | +| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | +| CWE-416 | Use After Free | +| CWE-434 | Unrestricted Upload of File with Dangerous Type | +| CWE-494 | Download of Code Without Integrity Check | +| CWE-502 | Deserialization of Untrusted Data | +| CWE-522 | Insufficiently Protected Credentials | +| CWE-611 | Improper Restriction of XML External Entity Reference | +| CWE-693 | Protection Mechanism Failure | +| CWE-798 | Use of Hard-coded Credentials | +| CWE-922 | Insecure Storage of Sensitive Information | +| CWE-1053 | Missing Documentation for Design | diff --git a/5.0/en/0x92-Appendix-C_Contributors.md b/5.0/en/0x92-Appendix-C_Contributors.md new file mode 100644 index 0000000..5c6ad06 --- /dev/null +++ b/5.0/en/0x92-Appendix-C_Contributors.md @@ -0,0 +1,28 @@ +# Appendix C - Contributors + +We gratefully acknowledge the contributions of the following people who have helped build and refine the TCASVS. + +## Project Leaders + +| | | +|---|---| +| Dave Hanson ([JeffreyShran](https://github.com/JeffreyShran)) | Project Lead | +| Samuel Aubert ([matreurai](https://github.com/matreurai)) | Project Lead | + +## Core Team (Bentley Systems) + +| | | +|---|---| +| Einaras Bartkus ([eb-bsi](https://github.com/eb-bsi)) | +| John Cotter | +| Thomas Chauchefoin | + +## OWASP Foundation + +| | | +|---|---| +| Starr Brown ([mamicidal](https://github.com/mamicidal)) | Director of Projects | + +## Community Contributors + +We thank all [contributors](https://github.com/OWASP/TCASVS/graphs/contributors) who have submitted issues, pull requests, and feedback to improve this standard. diff --git a/5.0/generate-all.sh b/5.0/generate-all.sh new file mode 100644 index 0000000..9b75227 --- /dev/null +++ b/5.0/generate-all.sh @@ -0,0 +1,55 @@ +#!/bin/bash +# Generate all TCASVS output formats. +# Run from the 5.0/ directory. + +set -e + +SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" +cd "$SCRIPT_DIR" + +echo "=== TCASVS Document Generation ===" +echo "" + +# Check prerequisites +if ! command -v python3 &>/dev/null; then + echo "Error: python3 is required. Run tools/install_deps.sh first." + exit 1 +fi + +# Always generate structured exports (no pandoc needed) +echo "Generating JSON..." +make json + +echo "Generating flat JSON..." +make json_flat + +echo "Generating CSV..." +make csv + +echo "Generating XML..." +make xml + +echo "Generating CycloneDX..." +make cdx_json + +# PDF/DOCX require pandoc + LaTeX +if command -v pandoc &>/dev/null; then + echo "Generating DOCX..." + make docx + + if command -v xelatex &>/dev/null; then + echo "Generating PDF..." + make pdf + else + echo "Skipping PDF (xelatex not found). Install texlive-xetex for PDF output." + fi +else + echo "Skipping PDF/DOCX (pandoc not found). Install pandoc for document outputs." +fi + +echo "" +echo "Verifying outputs..." +make verify + +echo "" +echo "Done. Outputs in 5.0/dist/" diff --git a/5.0/images/license.png b/5.0/images/license.png new file mode 100644 index 0000000..124d3ba Binary files /dev/null and b/5.0/images/license.png differ diff --git a/5.0/images/owasp_logo_1c_notext.png b/5.0/images/owasp_logo_1c_notext.png new file mode 100644 index 0000000..8f71f82 Binary files /dev/null and b/5.0/images/owasp_logo_1c_notext.png differ diff --git a/5.0/mappings/README.md b/5.0/mappings/README.md new file mode 100644 index 0000000..8ed90b6 --- /dev/null +++ b/5.0/mappings/README.md @@ -0,0 +1,47 @@ +# TCASVS Mapping Files + +This directory contains machine-readable mappings between the original TASVS requirement IDs and the new TCASVS v5.0.0 structure. + +## Files + +| File | Direction | Format | +|------|-----------|--------| +| `mapping_tasvs_to_tcasvs_v5.0.0.yml` | TASVS → TCASVS v5.0.0 | YAML | + +## Actions + +Each entry specifies one of the following actions: + +| Action | Meaning | +|--------|---------| +| `rename` | Requirement kept in the same logical location, reworded for ASVS format | +| `move` | Requirement moved to a different chapter (new ID in a different Vx.y.z) | +| `drop` | Requirement removed (not verifiable, out of scope, or absorbed by another) | +| `add` | New requirement with no TASVS predecessor (gap fill) | + +## Usage + +These mappings enable: +- Automated migration of existing TASVS assessment results to TCASVS IDs +- Traceability audits for compliance programs transitioning from TASVS to TCASVS +- Tooling that generates comparison reports between old and new assessments + +## Format + +```yaml +tasvs-arch-1-1: + action: rename + tcasvs-id: V1.1.1 + cwe: 1053 + notes: "Brief rationale for the change" +``` + +New requirements (no TASVS predecessor) use a `new-` prefix: + +```yaml +new-V1.3.1: + action: add + tcasvs-id: V1.3.1 + cwe: 250 + rationale: "Gap: thick clients need privilege separation documentation" +``` diff --git a/5.0/mappings/mapping_tasvs_to_tcasvs_v5.0.0.yml b/5.0/mappings/mapping_tasvs_to_tcasvs_v5.0.0.yml new file mode 100644 index 0000000..c51840b --- /dev/null +++ b/5.0/mappings/mapping_tasvs_to_tcasvs_v5.0.0.yml @@ -0,0 +1,858 @@ +# TASVS to TCASVS v5.0.0 Mapping +# Generated from migration/mapping/ workspace files +# +# Format follows ASVS mapping conventions. +# Actions: rename, move, drop, add +--- + +tasvs-arch-1-1: + action: rename + tcasvs-id: V1.1.1 + cwe: 1053 + notes: "Reworded: \"low fidelity\" is subjective; replaced with minimum content requirements" + +tasvs-arch-1-2: + action: rename + tcasvs-id: V1.1.2 + cwe: 1053 + notes: "Reworded: made \"high fidelity\" concrete with DFDs, classification, and mitigations" + +tasvs-arch-1-3: + action: rename + tcasvs-id: V1.1.3 + cwe: 1053 + notes: Reworded for precision; kept L2/L3 + +tasvs-arch-1-4: + action: rename + tcasvs-id: V1.2.1 + cwe: 1053 + notes: Moved to Process section; added ownership of mitigations + +tasvs-arch-1-5: + action: rename + tcasvs-id: V1.1.4 + cwe: 1053 + notes: "Reworded: made \"checked-in\" concrete with versioning and review expectations" + +tasvs-arch-1-6: + action: rename + tcasvs-id: V1.2.2 + cwe: 1053 + notes: "Reworded: added trigger-based updates (not just time-based)" + +new-V1.1.5: + action: add + tcasvs-id: V1.1.5 + cwe: 501 + rationale: "Gap: trust boundaries are the foundation of thick-client security analysis" + +new-V1.1.6: + action: add + tcasvs-id: V1.1.6 + cwe: 319 + rationale: "Gap: thick clients move data across many boundary types (memory→disk, process→process, client→server)" + +new-V1.2.3: + action: add + tcasvs-id: V1.2.3 + cwe: 1053 + rationale: "Gap: threat models drift from implementation; L3 requires verification" + +new-V1.2.4: + action: add + tcasvs-id: V1.2.4 + cwe: 1053 + rationale: "Gap: threat models must drive test coverage, not just exist as documents" + +new-V1.3.1: + action: add + tcasvs-id: V1.3.1 + cwe: 250 + rationale: "Gap: thick clients often use multi-process privilege separation (broker + renderer, service + UI)" + +new-V1.3.2: + action: add + tcasvs-id: V1.3.2 + cwe: 657 + rationale: "Gap: design-level decisions need documentation to be verifiable" + +new-V1.3.3: + action: add + tcasvs-id: V1.3.3 + cwe: 284 + rationale: "Gap: plugin architectures are common in thick clients (IDEs, browsers, media tools) and high-risk" + +new-V1.3.4: + action: add + tcasvs-id: V1.3.4 + cwe: 494 + rationale: "Gap: update architecture decisions (V1) distinct from implementation testing (V2.3)" + +new-V1.3.5: + action: add + tcasvs-id: V1.3.5 + cwe: 693 + rationale: "Gap: unique thick-client constraint — the platform itself is untrusted; L3 only for high-assurance apps" + +new-V1.4.1: + action: add + tcasvs-id: V1.4.1 + cwe: 1059 + rationale: "Gap: thick clients have large, diverse attack surfaces that must be explicitly enumerated" + +new-V1.4.2: + action: add + tcasvs-id: V1.4.2 + cwe: 306 + rationale: "Gap: knowing who can reach each interface is essential for thick-client security" + +new-V1.4.3: + action: add + tcasvs-id: V1.4.3 + cwe: 693 + rationale: "Gap: original TASVS-ARCH was generic; must require thick-client-specific threat coverage" + +new-V1.4.4: + action: add + tcasvs-id: V1.4.4 + cwe: 1053 + rationale: "Gap: attack surface management is ongoing, not one-time" + +tasvs-code-1-1: + action: drop + tcasvs-id: null + notes: "Not a verifiable requirement; deferral to ASVS is a project-level note, not a control. Documented in chapter introduction instead" + +tasvs-code-2-1: + action: move + tcasvs-id: V2.1.7 + cwe: 345 + notes: Build/release concern; already covered in V2.1.7. Level changed from L3-only to L2+ (signing is baseline for distribution) + +tasvs-code-2-2: + action: rename + tcasvs-id: V4.4.1 + cwe: 354 + notes: Reworded to be specific about mechanism and failure mode; moved to L2+ + +tasvs-code-2-3: + action: rename + tcasvs-id: V4.4.2 + cwe: 693 + notes: Kept at L3; anti-tamper is defence-in-depth for high-assurance deployments + +tasvs-code-2-4: + action: move + tcasvs-id: V2.1.3 + cwe: 489 + notes: Build configuration concern; already covered by V2.1.3 + V2.1.6 (debug symbols) + +tasvs-code-2-5: + action: move + tcasvs-id: V2.2.1 + cwe: 120 + notes: Compiler flags are build-time; already covered in V2.2.1-2.2.5 + +tasvs-code-3-1: + action: move + tcasvs-id: V2.1.4 + cwe: 829 + notes: Supply chain concern; already covered by V2.1.4 + V2.1.5 (SBOM) + +tasvs-code-3-2: + action: rename + tcasvs-id: V4.6.1 + cwe: 209 + notes: "Reworded from \"search for\" (testing activity) to verifiable runtime behaviour" + +tasvs-code-3-3: + action: rename + tcasvs-id: V4.6.2 + cwe: 1078 + notes: Kept as verification activity; L2+ since binary analysis requires tooling investment + +tasvs-code-3-4: + action: rename + tcasvs-id: V4.6.3 + cwe: 1078 + notes: Reworded for specificity; L1 baseline since modern SAST is accessible + +tasvs-code-3-5: + action: rename + tcasvs-id: V4.6.4 + cwe: 657 + notes: Reworded; moved to L2+ as a maturity requirement + +tasvs-code-3-6: + action: rename + tcasvs-id: V4.6.5 + cwe: 561 + notes: Reworded for specificity; L2+ maturity + +tasvs-code-4-1: + action: rename + tcasvs-id: V4.1.1 + cwe: 94 + notes: Reworded; added concrete mitigations + +tasvs-code-4-2: + action: rename + tcasvs-id: V4.1.2 + cwe: 78 + notes: Reworded; aligned with ASVS 1.2.5; added allowlist guidance + +tasvs-code-4-3: + action: rename + tcasvs-id: V4.1.3 + cwe: 20 + notes: Reworded for clarity + +tasvs-code-4-4: + action: rename + tcasvs-id: V4.3.1 + cwe: 611 + notes: Moved to V4.3 (deserialization); expanded to include DTD and XInclude + +tasvs-code-4-5: + action: rename + tcasvs-id: V4.2.1 + cwe: 120 + notes: Reworded; aligned with ASVS 1.4.1 but elevated to L1 for thick clients + +tasvs-code-4-6: + action: rename + tcasvs-id: V4.2.2 + cwe: 134 + notes: Reworded for precision; added compile-time constant guidance + +tasvs-code-4-7: + action: rename + tcasvs-id: V4.2.3 + cwe: 190 + notes: Reworded; added underflow and truncation; elevated to L1 for thick clients + +tasvs-code-4-8: + action: rename + tcasvs-id: V4.3.2 + cwe: 502 + notes: "Reworded; made mechanism explicit; removed \"encryption\" (that's V5 territory)" + +tasvs-code-4-9: + action: rename + tcasvs-id: V4.3.3 + cwe: 502 + notes: Reworded; aligned with ASVS 1.5.2; added concrete safe patterns + +tasvs-code-4-10: + action: rename + tcasvs-id: V4.1.4 + cwe: 78 + notes: Reworded; added fully-qualified paths; combines with CODE-7.1 concern + +tasvs-code-4-11: + action: rename + tcasvs-id: V4.1.5 + cwe: 22 + notes: Reworded; made ZipSlip and null byte explicit; aligned with ASVS 5.3.2/5.3.3 + +tasvs-code-4-12: + action: rename + tcasvs-id: V4.2.4 + cwe: 416 + notes: Reworded; added specific vulnerability types; elevated to L1 for thick clients + +tasvs-code-5-1: + action: move + tcasvs-id: V3.2.1 + cwe: 200 + notes: "Moved to V3; \"sensitive data in UI\" is a data protection concern" + +tasvs-code-5-2: + action: rename + tcasvs-id: V4.5.1 + cwe: 451 + notes: Reworded for specificity; concrete examples of harm + +tasvs-code-5-3: + action: rename + tcasvs-id: V4.5.2 + cwe: 657 + notes: "Reworded; made \"common security advice\" concrete" + +tasvs-code-5-4: + action: move + tcasvs-id: V2.4.6 + cwe: 265 + notes: Architecture/deployment concern; already covered in V2.4.6 + +tasvs-code-5-5: + action: rename + tcasvs-id: V4.1.6 + cwe: 434 + notes: Reworded; made thick-client file parsing threat explicit + +tasvs-code-5-6: + action: rename + tcasvs-id: V4.5.3 + cwe: 939 + notes: Reworded; expanded to cover parameter validation and user confirmation + +tasvs-code-6-1: + action: rename + tcasvs-id: V4.6.6 + cwe: 120 + notes: Reworded; made target interfaces specific; moved to L2+ (requires tooling) + +tasvs-code-6-2: + action: rename + tcasvs-id: V4.6.7 + cwe: 120 + notes: Reworded; kept at L3; high-maturity verification activity + +tasvs-code-7-1: + action: move + tcasvs-id: V2.3.5 + cwe: 427 + notes: Already covered in V2.3.5; DLL/EXE hijacking is a deployment concern + +tasvs-code-7-2: + action: rename + tcasvs-id: V4.2.5 + cwe: 59 + notes: Reworded; added concrete mitigations; assigned L1 (symlink attacks are common on multi-user systems) + +new-V4.1.7: + action: add + tcasvs-id: V4.1.7 + cwe: 20 + rationale: "Gap: IPC is a primary thick-client input vector often treated as \"trusted\"" + +new-V4.1.8: + action: add + tcasvs-id: V4.1.8 + cwe: 94 + rationale: "Gap: dynamic code execution in thick clients enables code injection via local vectors" + +new-V4.2.6: + action: add + tcasvs-id: V4.2.6 + cwe: 121 + rationale: "Gap: verification that build mitigations are actually present in shipped binaries" + +new-V4.2.7: + action: add + tcasvs-id: V4.2.7 + cwe: 122 + rationale: "Gap: heap exploitation is a major thick-client attack vector" + +new-V4.3.4: + action: add + tcasvs-id: V4.3.4 + cwe: 502 + rationale: "Gap: IPC-based deserialization attacks between local processes" + +new-V4.4.3: + action: add + tcasvs-id: V4.4.3 + cwe: 693 + rationale: "Gap: anti-debugging for high-assurance clients; L3 defence-in-depth" + +new-V4.5.4: + action: add + tcasvs-id: V4.5.4 + cwe: 829 + rationale: "Gap: plugin architectures in thick clients are a major attack surface" + +new-V4.5.5: + action: add + tcasvs-id: V4.5.5 + cwe: 20 + rationale: "Gap: alternative input paths often bypass file-open validation logic" + +new-V4.6.8: + action: add + tcasvs-id: V4.6.8 + cwe: 252 + rationale: "Gap: unchecked return values in native code lead to null dereferences and undefined behaviour" + +tasvs-conf-1-1: + action: rename + tcasvs-id: V2.1.1 + cwe: 657 + notes: Reworded; added reproducibility and build environment integrity + +tasvs-conf-1-2: + action: rename + tcasvs-id: V2.2.1 + cwe: 120 + notes: Moved to Environment Hardening; reworded for clarity + +tasvs-conf-1-3: + action: rename + tcasvs-id: V2.1.2 + cwe: 693 + notes: Kept; kept L2/L3 restriction as per original + +tasvs-conf-1-4: + action: rename + tcasvs-id: V2.1.3 + cwe: 489 + notes: Reworded; explicit about test utilities and dev configs + +tasvs-conf-1-5: + action: rename + tcasvs-id: V2.1.4 + cwe: 829 + notes: Added integrity verification; aligns with ASVS 15.2.4 + +tasvs-conf-1-6: + action: rename + tcasvs-id: V2.1.5 + cwe: 1104 + notes: Added transitive dependencies and release cadence; aligns with ASVS 15.1.2 + +tasvs-conf-2-1: + action: rename + tcasvs-id: V2.4.1 + cwe: 250 + notes: Reworded for clarity; made IPC surface minimization explicit + +tasvs-conf-2-2: + action: rename + tcasvs-id: V2.4.2 + cwe: 250 + notes: "Reworded for precision; original \"Rule of 2\" kept" + +tasvs-conf-2-3: + action: rename + tcasvs-id: V2.4.3 + cwe: 732 + notes: Reworded; added explicit access types + +new-V2.1.6: + action: add + tcasvs-id: V2.1.6 + cwe: 215 + rationale: "Gap: debug symbols enable reverse engineering and info disclosure" + +new-V2.1.7: + action: add + tcasvs-id: V2.1.7 + cwe: 345 + rationale: "Gap: unsigned binaries allow tampering and impersonation" + +new-V2.1.8: + action: add + tcasvs-id: V2.1.8 + cwe: 427 + rationale: "Gap: supply chain attack vector; aligns with ASVS 15.2.4" + +new-V2.2.2: + action: add + tcasvs-id: V2.2.2 + cwe: 119 + rationale: "Gap: ASLR is a fundamental exploit mitigation for thick clients" + +new-V2.2.3: + action: add + tcasvs-id: V2.2.3 + cwe: 119 + rationale: "Gap: DEP prevents shellcode execution from stack/heap" + +new-V2.2.4: + action: add + tcasvs-id: V2.2.4 + cwe: 691 + rationale: "Gap: CFI blocks ROP/JOP exploitation techniques" + +new-V2.2.5: + action: add + tcasvs-id: V2.2.5 + cwe: 119 + rationale: "Gap: latest generation hardware mitigations; L3 only" + +new-V2.2.6: + action: add + tcasvs-id: V2.2.6 + cwe: 693 + rationale: "Gap: applications sometimes weaken their own protections" + +new-V2.3.1: + action: add + tcasvs-id: V2.3.1 + cwe: 354 + rationale: "Gap: installer tampering is a common thick-client supply chain attack" + +new-V2.3.2: + action: add + tcasvs-id: V2.3.2 + cwe: 379 + rationale: "Gap: temp-file race conditions during installation" + +new-V2.3.3: + action: add + tcasvs-id: V2.3.3 + cwe: 494 + rationale: "Gap: unsigned updates allow arbitrary code execution" + +new-V2.3.4: + action: add + tcasvs-id: V2.3.4 + cwe: 295 + rationale: "Gap: MITM on update channel enables code injection" + +new-V2.3.5: + action: add + tcasvs-id: V2.3.5 + cwe: 427 + rationale: "Gap: DLL sideloading is one of the most common thick-client attacks" + +new-V2.3.6: + action: add + tcasvs-id: V2.3.6 + cwe: 269 + rationale: "Gap: installers often request full admin unnecessarily" + +new-V2.4.4: + action: add + tcasvs-id: V2.4.4 + cwe: 250 + rationale: "Gap: services running as SYSTEM widen blast radius" + +new-V2.4.5: + action: add + tcasvs-id: V2.4.5 + cwe: 732 + rationale: "Gap: config tampering enables privilege escalation" + +new-V2.4.6: + action: add + tcasvs-id: V2.4.6 + cwe: 265 + rationale: "Gap: sandbox missing for risky thick-client components" + +new-V2.4.7: + action: add + tcasvs-id: V2.4.7 + cwe: 732 + rationale: "Gap: open IPC objects allow local privilege escalation" + +tasvs-crypto-1-1: + action: rename + tcasvs-id: V5.6.1 + cwe: 326 + notes: Moved to Transport section + +tasvs-crypto-2-1: + action: move + tcasvs-id: V5.5.1 + cwe: 323 + notes: Raised L1→L2; moved to Key Management + +tasvs-crypto-2-2: + action: rename + tcasvs-id: V5.4.1 + cwe: 338 + notes: "Strengthened: 128-bit entropy minimum" + +tasvs-crypto-2-3: + action: rename + tcasvs-id: V5.3.1 + cwe: 327 + notes: Added examples + +tasvs-crypto-2-4: + action: rename + tcasvs-id: V5.5.2 + cwe: 321 + notes: "Strengthened: binary extraction" + +tasvs-crypto-3-1: + action: move + tcasvs-id: V5.2.1 + cwe: 310 + notes: Raised L1→L2; moved to Implementation + +tasvs-crypto-3-2: + action: rename + tcasvs-id: V5.2.2 + cwe: 327 + notes: Moved to Implementation section + +new-V5.1.1: + action: add + tcasvs-id: V5.1.1 + cwe: 320 + rationale: "Gap: ASVS 11.1.1" + +new-V5.1.2: + action: add + tcasvs-id: V5.1.2 + cwe: 311 + rationale: "Gap: ASVS 11.1.2" + +new-V5.2.3: + action: add + tcasvs-id: V5.2.3 + cwe: 327 + rationale: "Gap: ASVS 11.2.2" + +new-V5.3.2: + action: add + tcasvs-id: V5.3.2 + cwe: 327 + rationale: "Gap: ASVS 11.3.1+11.3.2" + +new-V5.3.3: + action: add + tcasvs-id: V5.3.3 + cwe: 326 + rationale: "Gap: ASVS 11.2.3" + +new-V5.4.2: + action: add + tcasvs-id: V5.4.2 + cwe: 332 + rationale: "Gap: ASVS 11.5.2" + +new-V5.5.3: + action: add + tcasvs-id: V5.5.3 + cwe: 312 + rationale: "Gap: thick-client-specific" + +new-V5.5.4: + action: add + tcasvs-id: V5.5.4 + cwe: 316 + rationale: "Gap: thick-client-specific" + +new-V5.6.2: + action: add + tcasvs-id: V5.6.2 + cwe: 295 + rationale: "Gap: thick-client-specific" + +new-V5.6.3: + action: add + tcasvs-id: V5.6.3 + cwe: 295 + rationale: "Gap: thick-client-specific" + +new-V5.6.4: + action: add + tcasvs-id: V5.6.4 + cwe: 494 + rationale: "Gap: thick-client-specific" + +tasvs-network-1-1: + action: rename + tcasvs-id: V6.3.1 + cwe: 319 + notes: Reworded for clarity; moved to Data Leakage section + +tasvs-network-1-2: + action: rename + tcasvs-id: V6.1.1 + cwe: 319 + notes: Core baseline requirement + +tasvs-network-4-4: + action: rename + tcasvs-id: V6.2.1 + cwe: 489 + notes: "Strengthened: added authentication requirement" + +new-V6.1.2: + action: add + tcasvs-id: V6.1.2 + cwe: 757 + rationale: "Gap: thick clients connect to multiple endpoints; mirrors ASVS 12.2.1" + +new-V6.1.3: + action: add + tcasvs-id: V6.1.3 + cwe: 319 + rationale: "Gap: thick clients often use non-HTTP protocols" + +new-V6.2.2: + action: add + tcasvs-id: V6.2.2 + cwe: 668 + rationale: "Gap: common misconfiguration in thick clients" + +new-V6.2.3: + action: add + tcasvs-id: V6.2.3 + cwe: 306 + rationale: "Gap: unauthenticated local services enable privilege escalation" + +new-V6.3.2: + action: add + tcasvs-id: V6.3.2 + cwe: 598 + rationale: "Gap: common leak vectors in thick clients with embedded browsers" + +new-V6.3.3: + action: add + tcasvs-id: V6.3.3 + cwe: 200 + rationale: "Gap: information disclosure via network traffic" + +new-V6.4.1: + action: add + tcasvs-id: V6.4.1 + cwe: 420 + rationale: "Gap: thick clients often use IPC with no access control" + +new-V6.4.2: + action: add + tcasvs-id: V6.4.2 + cwe: 345 + rationale: "Gap: local MITM between thick client components" + +new-V6.5.1: + action: add + tcasvs-id: V6.5.1 + cwe: 294 + rationale: "Gap: license bypass via replay is common thick-client attack" + +new-V6.5.2: + action: add + tcasvs-id: V6.5.2 + cwe: 636 + rationale: "Gap: offline bypass of license checks" + +tasvs-storage-1-6: + action: rename + tcasvs-id: V3.1.1 + cwe: 922 + notes: Reworded to align with ASVS 14.1.1/14.1.2; added classification duty; moved to L2 baseline (classification is a design-time activity) + +tasvs-storage-1-1: + action: rename + tcasvs-id: V3.2.1 + cwe: 798 + notes: "Reworded for clarity; broadened to \"application data files\"" + +tasvs-storage-1-2: + action: rename + tcasvs-id: V3.2.2 + cwe: 798 + notes: Reworded; added plist for macOS coverage + +tasvs-storage-1-3: + action: rename + tcasvs-id: V3.2.3 + cwe: 532 + notes: Reworded for precision; explicit about session tokens + +tasvs-storage-1-5: + action: rename + tcasvs-id: V3.2.4 + cwe: 798 + notes: Reworded; made the threat model explicit (string extraction) + +tasvs-storage-1-7: + action: rename + tcasvs-id: V3.3.1 + cwe: 522 + notes: Reworded; specified concrete secure storage APIs + +tasvs-storage-1-6: + action: merge + tcasvs-id: V3.3.2 + cwe: 311 + notes: Derived from STORAGE-1.6 encryption requirement; refocused as a storage control (crypto details deferred to V5) + +tasvs-storage-1-4: + action: rename + tcasvs-id: V3.4.1 + cwe: 316 + notes: "Reworded; made \"explicitly zeroed\" actionable" + +tasvs-storage-2-1: + action: move + tcasvs-id: V2.3.5 + cwe: 427 + notes: "Moved to V2.3.5 — this is a code integrity / deployment issue, not data storage. V2.3.5 already covers DLL replacement and proxying" + +tasvs-storage-2-2: + action: move + tcasvs-id: V2.3.5 + cwe: 427 + notes: Merged with STORAGE-2.1 into V2.3.5; no new requirement needed + +new-V3.1.2: + action: add + tcasvs-id: V3.1.2 + cwe: 922 + rationale: "Gap: no retention/deletion policy in old standard; aligns with GDPR minimization principle" + +new-V3.2.5: + action: add + tcasvs-id: V3.2.5 + cwe: 311 + rationale: "Gap: thick clients often use local DBs with no protection" + +new-V3.2.6: + action: add + tcasvs-id: V3.2.6 + cwe: 530 + rationale: "Gap: backup files often contain unprotected copies of sensitive data" + +new-V3.3.3: + action: add + tcasvs-id: V3.3.3 + cwe: 522 + rationale: "Gap: old standard acknowledged the problem but didn't specify the solution (platform APIs)" + +new-V3.3.4: + action: add + tcasvs-id: V3.3.4 + cwe: 321 + rationale: "Gap: hardware key protection for high-assurance deployments" + +new-V3.4.2: + action: add + tcasvs-id: V3.4.2 + cwe: 316 + rationale: "Gap: swap/pagefile exposure is a real thick-client threat" + +new-V3.4.3: + action: add + tcasvs-id: V3.4.3 + cwe: 200 + rationale: "Gap: clipboard is accessible to all processes; common data leak vector" + +new-V3.4.4: + action: add + tcasvs-id: V3.4.4 + cwe: 215 + rationale: "Gap: crash dumps often contain full process memory including secrets" + +new-V3.5.1: + action: add + tcasvs-id: V3.5.1 + cwe: 459 + rationale: "Gap: temp files persist after process exit and are readable by other users" + +new-V3.5.2: + action: add + tcasvs-id: V3.5.2 + cwe: 377 + rationale: "Gap: shared temp dirs allow symlink attacks and data theft" + +new-V3.5.3: + action: add + tcasvs-id: V3.5.3 + cwe: 459 + rationale: "Gap: residual data persists after logout/uninstall" + +new-V3.5.4: + action: add + tcasvs-id: V3.5.4 + cwe: 319 + rationale: "Gap: thick clients sometimes pass secrets via files or env vars between components" + diff --git a/5.0/templates/eisvogel.tex b/5.0/templates/eisvogel.tex new file mode 100644 index 0000000..1902734 --- /dev/null +++ b/5.0/templates/eisvogel.tex @@ -0,0 +1,1048 @@ +%% +% Copyright (c) 2017 - 2021, Pascal Wagler; +% Copyright (c) 2014 - 2021, John MacFarlane +% +% All rights reserved. +% +% Redistribution and use in source and binary forms, with or without +% modification, are permitted provided that the following conditions +% are met: +% +% - Redistributions of source code must retain the above copyright +% notice, this list of conditions and the following disclaimer. +% +% - Redistributions in binary form must reproduce the above copyright +% notice, this list of conditions and the following disclaimer in the +% documentation and/or other materials provided with the distribution. +% +% - Neither the name of John MacFarlane nor the names of other +% contributors may be used to endorse or promote products derived +% from this software without specific prior written permission. +% +% THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +% "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +% LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS +% FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE +% COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +% INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +% BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; +% LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER +% CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +% LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +% ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +% POSSIBILITY OF SUCH DAMAGE. +%% + +%% +% This is the Eisvogel pandoc LaTeX template. +% +% For usage information and examples visit the official GitHub page: +% https://github.com/Wandmalfarbe/pandoc-latex-template +%% + +% Options for packages loaded elsewhere +\PassOptionsToPackage{unicode$for(hyperrefoptions)$,$hyperrefoptions$$endfor$}{hyperref} +\PassOptionsToPackage{hyphens}{url} +\PassOptionsToPackage{dvipsnames,svgnames,x11names,table}{xcolor} +$if(dir)$ +$if(latex-dir-rtl)$ +\PassOptionsToPackage{RTLdocument}{bidi} +$endif$ +$endif$ +$if(CJKmainfont)$ +\PassOptionsToPackage{space}{xeCJK} +$endif$ +% +\documentclass[ +$if(fontsize)$ + $fontsize$, +$endif$ +$if(lang)$ + $babel-lang$, +$endif$ +$if(papersize)$ + $papersize$paper, +$else$ + paper=a4, +$endif$ +$if(beamer)$ + ignorenonframetext, +$if(handout)$ + handout, +$endif$ +$if(aspectratio)$ + aspectratio=$aspectratio$, +$endif$ +$endif$ +$for(classoption)$ + $classoption$$sep$, +$endfor$ + ,captions=tableheading +]{$if(beamer)$$documentclass$$else$$if(book)$scrbook$else$scrartcl$endif$$endif$} +$if(beamer)$ +$if(background-image)$ +\usebackgroundtemplate{% + \includegraphics[width=\paperwidth]{$background-image$}% +} +$endif$ +\usepackage{pgfpages} +\setbeamertemplate{caption}[numbered] +\setbeamertemplate{caption label separator}{: } +\setbeamercolor{caption name}{fg=normal text.fg} +\beamertemplatenavigationsymbols$if(navigation)$$navigation$$else$empty$endif$ +$for(beameroption)$ +\setbeameroption{$beameroption$} +$endfor$ +% Prevent slide breaks in the middle of a paragraph +\widowpenalties 1 10000 +\raggedbottom +$if(section-titles)$ +\setbeamertemplate{part page}{ + \centering + \begin{beamercolorbox}[sep=16pt,center]{part title} + \usebeamerfont{part title}\insertpart\par + \end{beamercolorbox} +} +\setbeamertemplate{section page}{ + \centering + \begin{beamercolorbox}[sep=12pt,center]{part title} + \usebeamerfont{section title}\insertsection\par + \end{beamercolorbox} +} +\setbeamertemplate{subsection page}{ + \centering + \begin{beamercolorbox}[sep=8pt,center]{part title} + \usebeamerfont{subsection title}\insertsubsection\par + \end{beamercolorbox} +} +\AtBeginPart{ + \frame{\partpage} +} +\AtBeginSection{ + \ifbibliography + \else + \frame{\sectionpage} + \fi +} +\AtBeginSubsection{ + \frame{\subsectionpage} +} +$endif$ +$endif$ +$if(beamerarticle)$ +\usepackage{beamerarticle} % needs to be loaded first +$endif$ +\usepackage{amsmath,amssymb} +$if(fontfamily)$ +\usepackage[$for(fontfamilyoptions)$$fontfamilyoptions$$sep$,$endfor$]{$fontfamily$} +$else$ +\usepackage{lmodern} +$endif$ +$if(linestretch)$ +\usepackage{setspace} +$else$ +\usepackage{setspace} +\setstretch{1.2} +$endif$ +\usepackage{iftex} +\ifPDFTeX + \usepackage[$if(fontenc)$$fontenc$$else$T1$endif$]{fontenc} + \usepackage[utf8]{inputenc} + \usepackage{textcomp} % provide euro and other symbols +\else % if luatex or xetex +$if(mathspec)$ + \ifXeTeX + \usepackage{mathspec} + \else + \usepackage{unicode-math} + \fi +$else$ + \usepackage{unicode-math} +$endif$ + \defaultfontfeatures{Scale=MatchLowercase} + \defaultfontfeatures[\rmfamily]{Ligatures=TeX,Scale=1} +$if(mainfont)$ + \setmainfont[$for(mainfontoptions)$$mainfontoptions$$sep$,$endfor$]{$mainfont$} +$endif$ +$if(sansfont)$ + \setsansfont[$for(sansfontoptions)$$sansfontoptions$$sep$,$endfor$]{$sansfont$} +$endif$ +$if(monofont)$ + \setmonofont[$for(monofontoptions)$$monofontoptions$$sep$,$endfor$]{$monofont$} +$endif$ +$for(fontfamilies)$ + \newfontfamily{$fontfamilies.name$}[$for(fontfamilies.options)$$fontfamilies.options$$sep$,$endfor$]{$fontfamilies.font$} +$endfor$ +$if(mathfont)$ +$if(mathspec)$ + \ifXeTeX + \setmathfont(Digits,Latin,Greek)[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$} + \else + \setmathfont[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$} + \fi +$else$ + \setmathfont[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$} +$endif$ +$endif$ +$if(CJKmainfont)$ + \ifXeTeX + \usepackage{xeCJK} + \setCJKmainfont[$for(CJKoptions)$$CJKoptions$$sep$,$endfor$]{$CJKmainfont$} + \fi +$endif$ +$if(luatexjapresetoptions)$ + \ifLuaTeX + \usepackage[$for(luatexjapresetoptions)$$luatexjapresetoptions$$sep$,$endfor$]{luatexja-preset} + \fi +$endif$ +$if(CJKmainfont)$ + \ifLuaTeX + \usepackage[$for(luatexjafontspecoptions)$$luatexjafontspecoptions$$sep$,$endfor$]{luatexja-fontspec} + \setmainjfont[$for(CJKoptions)$$CJKoptions$$sep$,$endfor$]{$CJKmainfont$} + \fi +$endif$ +\fi +$if(zero-width-non-joiner)$ +%% Support for zero-width non-joiner characters. +\makeatletter +\def\zerowidthnonjoiner{% + % Prevent ligatures and adjust kerning, but still support hyphenating. + \texorpdfstring{% + \textormath{\nobreak\discretionary{-}{}{\kern.03em}% + \ifvmode\else\nobreak\hskip\z@skip\fi}{}% + }{}% +} +\makeatother +\ifPDFTeX + \DeclareUnicodeCharacter{200C}{\zerowidthnonjoiner} +\else + \catcode`^^^^200c=\active + \protected\def ^^^^200c{\zerowidthnonjoiner} +\fi +%% End of ZWNJ support +$endif$ +$if(beamer)$ +$if(theme)$ +\usetheme[$for(themeoptions)$$themeoptions$$sep$,$endfor$]{$theme$} +$endif$ +$if(colortheme)$ +\usecolortheme{$colortheme$} +$endif$ +$if(fonttheme)$ +\usefonttheme{$fonttheme$} +$endif$ +$if(mainfont)$ +\usefonttheme{serif} % use mainfont rather than sansfont for slide text +$endif$ +$if(innertheme)$ +\useinnertheme{$innertheme$} +$endif$ +$if(outertheme)$ +\useoutertheme{$outertheme$} +$endif$ +$endif$ +% Use upquote if available, for straight quotes in verbatim environments +\IfFileExists{upquote.sty}{\usepackage{upquote}}{} +\IfFileExists{microtype.sty}{% use microtype if available + \usepackage[$for(microtypeoptions)$$microtypeoptions$$sep$,$endfor$]{microtype} + \UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts +}{} +$if(indent)$ +$else$ +\makeatletter +\@ifundefined{KOMAClassName}{% if non-KOMA class + \IfFileExists{parskip.sty}{% + \usepackage{parskip} + }{% else + \setlength{\parindent}{0pt} + \setlength{\parskip}{6pt plus 2pt minus 1pt}} +}{% if KOMA class + \KOMAoptions{parskip=half}} +\makeatother +$endif$ +$if(verbatim-in-note)$ +\usepackage{fancyvrb} +$endif$ +\usepackage{xcolor} +\definecolor{default-linkcolor}{HTML}{A50000} +\definecolor{default-filecolor}{HTML}{A50000} +\definecolor{default-citecolor}{HTML}{4077C0} +\definecolor{default-urlcolor}{HTML}{4077C0} +\IfFileExists{xurl.sty}{\usepackage{xurl}}{} % add URL line breaks if available +$if(footnotes-pretty)$ +% load footmisc in order to customize footnotes (footmisc has to be loaded before hyperref, cf. https://tex.stackexchange.com/a/169124/144087) +\usepackage[hang,flushmargin,bottom,multiple]{footmisc} +\setlength{\footnotemargin}{0.8em} % set space between footnote nr and text +\setlength{\footnotesep}{\baselineskip} % set space between multiple footnotes +\setlength{\skip\footins}{0.3cm} % set space between page content and footnote +\setlength{\footskip}{0.9cm} % set space between footnote and page bottom +$endif$ +\IfFileExists{bookmark.sty}{\usepackage{bookmark}}{\usepackage{hyperref}} +\hypersetup{ +$if(title-meta)$ + pdftitle={$title-meta$}, +$endif$ +$if(author-meta)$ + pdfauthor={$author-meta$}, +$endif$ +$if(lang)$ + pdflang={$lang$}, +$endif$ +$if(subject)$ + pdfsubject={$subject$}, +$endif$ +$if(keywords)$ + pdfkeywords={$for(keywords)$$keywords$$sep$, $endfor$}, +$endif$ +$if(colorlinks)$ + colorlinks=true, + linkcolor={$if(linkcolor)$$linkcolor$$else$default-linkcolor$endif$}, + filecolor={$if(filecolor)$$filecolor$$else$default-filecolor$endif$}, + citecolor={$if(citecolor)$$citecolor$$else$default-citecolor$endif$}, + urlcolor={$if(urlcolor)$$urlcolor$$else$default-urlcolor$endif$}, +$else$ + hidelinks, +$endif$ + breaklinks=true, + pdfcreator={LaTeX via pandoc with the Eisvogel template}} +\urlstyle{same} % disable monospaced font for URLs +$if(verbatim-in-note)$ +\VerbatimFootnotes % allow verbatim text in footnotes +$endif$ +$if(geometry)$ +$if(beamer)$ +\geometry{$for(geometry)$$geometry$$sep$,$endfor$} +$else$ +\usepackage[$for(geometry)$$geometry$$sep$,$endfor$]{geometry} +$endif$ +$else$ +$if(beamer)$ +$else$ +\usepackage[margin=2.5cm,includehead=true,includefoot=true,centering,$for(geometry)$$geometry$$sep$,$endfor$]{geometry} +$endif$ +$endif$ +$if(titlepage-logo)$ +\usepackage[export]{adjustbox} +\usepackage{graphicx} +$endif$ +$if(beamer)$ +\newif\ifbibliography +$endif$ +$if(listings)$ +\usepackage{listings} +\newcommand{\passthrough}[1]{#1} +\lstset{defaultdialect=[5.3]Lua} +\lstset{defaultdialect=[x86masm]Assembler} +$endif$ +$if(listings-no-page-break)$ +\usepackage{etoolbox} +\BeforeBeginEnvironment{lstlisting}{\par\noindent\begin{minipage}{\linewidth}} +\AfterEndEnvironment{lstlisting}{\end{minipage}\par\addvspace{\topskip}} +$endif$ +$if(lhs)$ +\lstnewenvironment{code}{\lstset{language=Haskell,basicstyle=\small\ttfamily}}{} +$endif$ +$if(highlighting-macros)$ +$highlighting-macros$ + +% Workaround/bugfix from jannick0. +% See https://github.com/jgm/pandoc/issues/4302#issuecomment-360669013) +% or https://github.com/Wandmalfarbe/pandoc-latex-template/issues/2 +% +% Redefine the verbatim environment 'Highlighting' to break long lines (with +% the help of fvextra). Redefinition is necessary because it is unlikely that +% pandoc includes fvextra in the default template. +\usepackage{fvextra} +\DefineVerbatimEnvironment{Highlighting}{Verbatim}{breaklines,fontsize=$if(code-block-font-size)$$code-block-font-size$$else$\small$endif$,commandchars=\\\{\}} + +$endif$ +$if(tables)$ +\usepackage{longtable,booktabs,array} +$if(multirow)$ +\usepackage{multirow} +$endif$ +\usepackage{calc} % for calculating minipage widths +$if(beamer)$ +\usepackage{caption} +% Make caption package work with longtable +\makeatletter +\def\fnum@table{\tablename~\thetable} +\makeatother +$else$ +% Correct order of tables after \paragraph or \subparagraph +\usepackage{etoolbox} +\makeatletter +\patchcmd\longtable{\par}{\if@noskipsec\mbox{}\fi\par}{}{} +\makeatother +% Allow footnotes in longtable head/foot +\IfFileExists{footnotehyper.sty}{\usepackage{footnotehyper}}{\usepackage{footnote}} +\makesavenoteenv{longtable} +$endif$ +$endif$ +% add backlinks to footnote references, cf. https://tex.stackexchange.com/questions/302266/make-footnote-clickable-both-ways +$if(footnotes-disable-backlinks)$ +$else$ +\usepackage{footnotebackref} +$endif$ +$if(graphics)$ +\usepackage{graphicx} +\makeatletter +\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi} +\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi} +\makeatother +% Scale images if necessary, so that they will not overflow the page +% margins by default, and it is still possible to overwrite the defaults +% using explicit options in \includegraphics[width, height, ...]{} +\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio} +% Set default figure placement to htbp +\makeatletter +\def\fps@figure{htbp} +\makeatother +$endif$ +$if(links-as-notes)$ +% Make links footnotes instead of hotlinks: +\DeclareRobustCommand{\href}[2]{#2\footnote{\url{#1}}} +$endif$ +$if(strikeout)$ +$-- also used for underline +\usepackage[normalem]{ulem} +% Avoid problems with \sout in headers with hyperref +\pdfstringdefDisableCommands{\renewcommand{\sout}{}} +$endif$ +\setlength{\emergencystretch}{3em} % prevent overfull lines +\providecommand{\tightlist}{% + \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}} +$if(numbersections)$ +\setcounter{secnumdepth}{$if(secnumdepth)$$secnumdepth$$else$5$endif$} +$else$ +\setcounter{secnumdepth}{-\maxdimen} % remove section numbering +$endif$ +$if(beamer)$ +$else$ +$if(block-headings)$ +% Make \paragraph and \subparagraph free-standing +\ifx\paragraph\undefined\else + \let\oldparagraph\paragraph + \renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}} +\fi +\ifx\subparagraph\undefined\else + \let\oldsubparagraph\subparagraph + \renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}} +\fi +$endif$ +$endif$ +$if(pagestyle)$ +\pagestyle{$pagestyle$} +$endif$ +$if(csl-refs)$ +\newlength{\cslhangindent} +\setlength{\cslhangindent}{1.5em} +\newlength{\csllabelwidth} +\setlength{\csllabelwidth}{3em} +\newlength{\cslentryspacingunit} % times entry-spacing +\setlength{\cslentryspacingunit}{\parskip} +\newenvironment{CSLReferences}[2] % #1 hanging-ident, #2 entry spacing + {% don't indent paragraphs + \setlength{\parindent}{0pt} + % turn on hanging indent if param 1 is 1 + \ifodd #1 + \let\oldpar\par + \def\par{\hangindent=\cslhangindent\oldpar} + \fi + % set entry spacing + \setlength{\parskip}{#2\cslentryspacingunit} + }% + {} +\usepackage{calc} +\newcommand{\CSLBlock}[1]{#1\hfill\break} +\newcommand{\CSLLeftMargin}[1]{\parbox[t]{\csllabelwidth}{#1}} +\newcommand{\CSLRightInline}[1]{\parbox[t]{\linewidth - \csllabelwidth}{#1}\break} +\newcommand{\CSLIndent}[1]{\hspace{\cslhangindent}#1} +$endif$ +$for(header-includes)$ +$header-includes$ +$endfor$ +$if(lang)$ +\usepackage[$for(babel-otherlangs)$$babel-otherlangs$,$endfor$main=$babel-lang$]{babel} +% get rid of language-specific shorthands (see #6817): +\let\LanguageShortHands\languageshorthands +\def\languageshorthands#1{} +$endif$ +\ifLuaTeX + \usepackage{selnolig} % disable illegal ligatures +\fi +$if(dir)$ +\ifXeTeX + % Load bidi as late as possible as it modifies e.g. graphicx + \usepackage{bidi} +\fi +\ifPDFTeX + \TeXXeTstate=1 + \newcommand{\RL}[1]{\beginR #1\endR} + \newcommand{\LR}[1]{\beginL #1\endL} + \newenvironment{RTL}{\beginR}{\endR} + \newenvironment{LTR}{\beginL}{\endL} +\fi +$endif$ +$if(natbib)$ +\usepackage[$natbiboptions$]{natbib} +\bibliographystyle{$if(biblio-style)$$biblio-style$$else$plainnat$endif$} +$endif$ +$if(biblatex)$ +\usepackage[$if(biblio-style)$style=$biblio-style$,$endif$$for(biblatexoptions)$$biblatexoptions$$sep$,$endfor$]{biblatex} +$for(bibliography)$ +\addbibresource{$bibliography$} +$endfor$ +$endif$ +$if(nocite-ids)$ +\nocite{$for(nocite-ids)$$it$$sep$, $endfor$} +$endif$ +$if(csquotes)$ +\usepackage{csquotes} +$endif$ + +$if(title)$ +\title{$title$$if(thanks)$\thanks{$thanks$}$endif$} +$endif$ +$if(subtitle)$ +$if(beamer)$ +$else$ +\usepackage{etoolbox} +\makeatletter +\providecommand{\subtitle}[1]{% add subtitle to \maketitle + \apptocmd{\@title}{\par {\large #1 \par}}{}{} +} +\makeatother +$endif$ +\subtitle{$subtitle$} +$endif$ +\author{$for(author)$$author$$sep$ \and $endfor$} +\date{$date$} +$if(beamer)$ +$if(institute)$ +\institute{$for(institute)$$institute$$sep$ \and $endfor$} +$endif$ +$if(titlegraphic)$ +\titlegraphic{\includegraphics{$titlegraphic$}} +$endif$ +$if(logo)$ +\logo{\includegraphics{$logo$}} +$endif$ +$endif$ + + + +%% +%% added +%% + +$if(page-background)$ +\usepackage[pages=all]{background} +$endif$ + +% +% for the background color of the title page +% +$if(titlepage)$ +\usepackage{pagecolor} +\usepackage{afterpage} +$if(titlepage-background)$ +\usepackage{tikz} +$endif$ +$if(geometry)$ +$else$ +\usepackage[margin=2.5cm,includehead=true,includefoot=true,centering]{geometry} +$endif$ +$endif$ + +% +% break urls +% +\PassOptionsToPackage{hyphens}{url} + +% +% When using babel or polyglossia with biblatex, loading csquotes is recommended +% to ensure that quoted texts are typeset according to the rules of your main language. +% +\usepackage{csquotes} + +% +% captions +% +\definecolor{caption-color}{HTML}{777777} +$if(beamer)$ +$else$ +\usepackage[font={stretch=1.2}, textfont={color=caption-color}, position=top, skip=4mm, labelfont=bf, singlelinecheck=false, justification=$if(caption-justification)$$caption-justification$$else$raggedright$endif$]{caption} +\setcapindent{0em} +$endif$ + +% +% blockquote +% +\definecolor{blockquote-border}{RGB}{221,221,221} +\definecolor{blockquote-text}{RGB}{119,119,119} +\usepackage{mdframed} +\newmdenv[rightline=false,bottomline=false,topline=false,linewidth=3pt,linecolor=blockquote-border,skipabove=\parskip]{customblockquote} +\renewenvironment{quote}{\begin{customblockquote}\list{}{\rightmargin=0em\leftmargin=0em}% +\item\relax\color{blockquote-text}\ignorespaces}{\unskip\unskip\endlist\end{customblockquote}} + +% +% Source Sans Pro as the de­fault font fam­ily +% Source Code Pro for monospace text +% +% 'default' option sets the default +% font family to Source Sans Pro, not \sfdefault. +% +\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex + $if(fontfamily)$ + $else$ + \usepackage[default]{sourcesans} + \usepackage{sourcecodepro} + $endif$ +\else % if not pdftex + $if(mainfont)$ + $else$ + \usepackage[default]{sourcesans} + \usepackage{sourcecodepro} + + % XeLaTeX specific adjustments for straight quotes: https://tex.stackexchange.com/a/354887 + % This issue is already fixed (see https://github.com/silkeh/latex-sourcecodepro/pull/5) but the + % fix is still unreleased. + % TODO: Remove this workaround when the new version of sourcecodepro is released on CTAN. + \ifxetex + \makeatletter + \defaultfontfeatures[\ttfamily] + { Numbers = \sourcecodepro@figurestyle, + Scale = \SourceCodePro@scale, + Extension = .otf } + \setmonofont + [ UprightFont = *-\sourcecodepro@regstyle, + ItalicFont = *-\sourcecodepro@regstyle It, + BoldFont = *-\sourcecodepro@boldstyle, + BoldItalicFont = *-\sourcecodepro@boldstyle It ] + {SourceCodePro} + \makeatother + \fi + $endif$ +\fi + +% +% heading color +% +\definecolor{heading-color}{RGB}{40,40,40} +$if(beamer)$ +$else$ +\addtokomafont{section}{\color{heading-color}} +$endif$ +% When using the classes report, scrreprt, book, +% scrbook or memoir, uncomment the following line. +%\addtokomafont{chapter}{\color{heading-color}} + +% +% variables for title, author and date +% +$if(beamer)$ +$else$ +\usepackage{titling} +\title{$title$} +\author{$for(author)$$author$$sep$, $endfor$} +\date{$date$} +$endif$ + +% +% tables +% +$if(tables)$ + +\definecolor{table-row-color}{HTML}{F5F5F5} +\definecolor{table-rule-color}{HTML}{999999} + +%\arrayrulecolor{black!40} +\arrayrulecolor{table-rule-color} % color of \toprule, \midrule, \bottomrule +\setlength\heavyrulewidth{0.3ex} % thickness of \toprule, \bottomrule +\renewcommand{\arraystretch}{1.3} % spacing (padding) + +$if(table-use-row-colors)$ +% TODO: This doesn't work anymore. I don't know why. +% Reset rownum counter so that each table +% starts with the same row colors. +% https://tex.stackexchange.com/questions/170637/restarting-rowcolors +% +% Unfortunately the colored cells extend beyond the edge of the +% table because pandoc uses @-expressions (@{}) like so: +% +% \begin{longtable}[]{@{}ll@{}} +% \end{longtable} +% +% https://en.wikibooks.org/wiki/LaTeX/Tables#.40-expressions +\let\oldlongtable\longtable +\let\endoldlongtable\endlongtable +\renewenvironment{longtable}{ +\rowcolors{3}{}{table-row-color!100} % row color +\oldlongtable} { +\endoldlongtable +\global\rownum=0\relax} +$endif$ +$endif$ + +% +% remove paragraph indention +% +\setlength{\parindent}{0pt} +\setlength{\parskip}{6pt plus 2pt minus 1pt} +\setlength{\emergencystretch}{3em} % prevent overfull lines + +% +% +% Listings +% +% + +$if(listings)$ + +% +% general listing colors +% +\definecolor{listing-background}{HTML}{F7F7F7} +\definecolor{listing-rule}{HTML}{B3B2B3} +\definecolor{listing-numbers}{HTML}{B3B2B3} +\definecolor{listing-text-color}{HTML}{000000} +\definecolor{listing-keyword}{HTML}{435489} +\definecolor{listing-keyword-2}{HTML}{1284CA} % additional keywords +\definecolor{listing-keyword-3}{HTML}{9137CB} % additional keywords +\definecolor{listing-identifier}{HTML}{435489} +\definecolor{listing-string}{HTML}{00999A} +\definecolor{listing-comment}{HTML}{8E8E8E} + +\lstdefinestyle{eisvogel_listing_style}{ + language = java, +$if(listings-disable-line-numbers)$ + xleftmargin = 0.6em, + framexleftmargin = 0.4em, +$else$ + numbers = left, + xleftmargin = 2.7em, + framexleftmargin = 2.5em, +$endif$ + backgroundcolor = \color{listing-background}, + basicstyle = \color{listing-text-color}\linespread{1.0}% + \lst@ifdisplaystyle% + $if(code-block-font-size)$$code-block-font-size$$else$\small$endif$% + \fi\ttfamily{}, + breaklines = true, + frame = single, + framesep = 0.19em, + rulecolor = \color{listing-rule}, + frameround = ffff, + tabsize = 4, + numberstyle = \color{listing-numbers}, + aboveskip = 1.0em, + belowskip = 0.1em, + abovecaptionskip = 0em, + belowcaptionskip = 1.0em, + keywordstyle = {\color{listing-keyword}\bfseries}, + keywordstyle = {[2]\color{listing-keyword-2}\bfseries}, + keywordstyle = {[3]\color{listing-keyword-3}\bfseries\itshape}, + sensitive = true, + identifierstyle = \color{listing-identifier}, + commentstyle = \color{listing-comment}, + stringstyle = \color{listing-string}, + showstringspaces = false, + escapeinside = {/*@}{@*/}, % Allow LaTeX inside these special comments + literate = + {á}{{\'a}}1 {é}{{\'e}}1 {í}{{\'i}}1 {ó}{{\'o}}1 {ú}{{\'u}}1 + {Á}{{\'A}}1 {É}{{\'E}}1 {Í}{{\'I}}1 {Ó}{{\'O}}1 {Ú}{{\'U}}1 + {à}{{\`a}}1 {è}{{\'e}}1 {ì}{{\`i}}1 {ò}{{\`o}}1 {ù}{{\`u}}1 + {À}{{\`A}}1 {È}{{\'E}}1 {Ì}{{\`I}}1 {Ò}{{\`O}}1 {Ù}{{\`U}}1 + {ä}{{\"a}}1 {ë}{{\"e}}1 {ï}{{\"i}}1 {ö}{{\"o}}1 {ü}{{\"u}}1 + {Ä}{{\"A}}1 {Ë}{{\"E}}1 {Ï}{{\"I}}1 {Ö}{{\"O}}1 {Ü}{{\"U}}1 + {â}{{\^a}}1 {ê}{{\^e}}1 {î}{{\^i}}1 {ô}{{\^o}}1 {û}{{\^u}}1 + {Â}{{\^A}}1 {Ê}{{\^E}}1 {Î}{{\^I}}1 {Ô}{{\^O}}1 {Û}{{\^U}}1 + {œ}{{\oe}}1 {Œ}{{\OE}}1 {æ}{{\ae}}1 {Æ}{{\AE}}1 {ß}{{\ss}}1 + {ç}{{\c c}}1 {Ç}{{\c C}}1 {ø}{{\o}}1 {å}{{\r a}}1 {Å}{{\r A}}1 + {€}{{\EUR}}1 {£}{{\pounds}}1 {«}{{\guillemotleft}}1 + {»}{{\guillemotright}}1 {ñ}{{\~n}}1 {Ñ}{{\~N}}1 {¿}{{?`}}1 + {…}{{\ldots}}1 {≥}{{>=}}1 {≤}{{<=}}1 {„}{{\glqq}}1 {“}{{\grqq}}1 + {”}{{''}}1 +} +\lstset{style=eisvogel_listing_style} + +% +% Java (Java SE 12, 2019-06-22) +% +\lstdefinelanguage{Java}{ + morekeywords={ + % normal keywords (without data types) + abstract,assert,break,case,catch,class,continue,default, + do,else,enum,exports,extends,final,finally,for,if,implements, + import,instanceof,interface,module,native,new,package,private, + protected,public,requires,return,static,strictfp,super,switch, + synchronized,this,throw,throws,transient,try,volatile,while, + % var is an identifier + var + }, + morekeywords={[2] % data types + % primitive data types + boolean,byte,char,double,float,int,long,short, + % String + String, + % primitive wrapper types + Boolean,Byte,Character,Double,Float,Integer,Long,Short + % number types + Number,AtomicInteger,AtomicLong,BigDecimal,BigInteger,DoubleAccumulator,DoubleAdder,LongAccumulator,LongAdder,Short, + % other + Object,Void,void + }, + morekeywords={[3] % literals + % reserved words for literal values + null,true,false, + }, + sensitive, + morecomment = [l]//, + morecomment = [s]{/*}{*/}, + morecomment = [s]{/**}{*/}, + morestring = [b]", + morestring = [b]', +} + +\lstdefinelanguage{XML}{ + morestring = [b]", + moredelim = [s][\bfseries\color{listing-keyword}]{<}{\ }, + moredelim = [s][\bfseries\color{listing-keyword}]{}, + moredelim = [l][\bfseries\color{listing-keyword}]{/>}, + moredelim = [l][\bfseries\color{listing-keyword}]{>}, + morecomment = [s]{}, + morecomment = [s]{}, + commentstyle = \color{listing-comment}, + stringstyle = \color{listing-string}, + identifierstyle = \color{listing-identifier} +} +$endif$ + +% +% header and footer +% +$if(beamer)$ +$else$ +$if(disable-header-and-footer)$ +$else$ +\usepackage[headsepline,footsepline]{scrlayer-scrpage} + +\newpairofpagestyles{eisvogel-header-footer}{ + \clearpairofpagestyles + \ihead*{$if(header-left)$$header-left$$else$$title$$endif$} + \chead*{$if(header-center)$$header-center$$else$$endif$} + \ohead*{$if(header-right)$$header-right$$else$$date$$endif$} + \ifoot*{$if(footer-left)$$footer-left$$else$$for(author)$$author$$sep$, $endfor$$endif$} + \cfoot*{$if(footer-center)$$footer-center$$else$$endif$} + \ofoot*{$if(footer-right)$$footer-right$$else$\thepage$endif$} + \addtokomafont{pageheadfoot}{\upshape} +} +\pagestyle{eisvogel-header-footer} + +$if(book)$ +\deftripstyle{ChapterStyle}{}{}{}{}{\pagemark}{} +\renewcommand*{\chapterpagestyle}{ChapterStyle} +$endif$ + +$if(page-background)$ +\backgroundsetup{ +scale=1, +color=black, +opacity=$if(page-background-opacity)$$page-background-opacity$$else$0.2$endif$, +angle=0, +contents={% + \includegraphics[width=\paperwidth,height=\paperheight]{$page-background$} + }% +} +$endif$ +$endif$ +$endif$ + +%% +%% end added +%% + +\begin{document} + +%% +%% begin titlepage +%% +$if(beamer)$ +$else$ +$if(titlepage)$ +\begin{titlepage} +$if(titlepage-background)$ +\newgeometry{top=2cm, right=4cm, bottom=3cm, left=4cm} +$else$ +\newgeometry{left=6cm} +$endif$ +$if(titlepage-color)$ +\definecolor{titlepage-color}{HTML}{$titlepage-color$} +\newpagecolor{titlepage-color}\afterpage{\restorepagecolor} +$endif$ +$if(titlepage-background)$ +\tikz[remember picture,overlay] \node[inner sep=0pt] at (current page.center){\includegraphics[width=\paperwidth,height=\paperheight]{$titlepage-background$}}; +$endif$ +\newcommand{\colorRule}[3][black]{\textcolor[HTML]{#1}{\rule{#2}{#3}}} +\begin{flushleft} +\noindent +\\[-1em] +\color[HTML]{$if(titlepage-text-color)$$titlepage-text-color$$else$5F5F5F$endif$} +\makebox[0pt][l]{\colorRule[$if(titlepage-rule-color)$$titlepage-rule-color$$else$435488$endif$]{1.3\textwidth}{$if(titlepage-rule-height)$$titlepage-rule-height$$else$4$endif$pt}} +\par +\noindent + +$if(titlepage-background)$ +% The titlepage with a background image has other text spacing and text size +{ + \setstretch{2} + \vfill + \vskip -8em + \noindent {\huge \textbf{\textsf{$title$}}} + $if(subtitle)$ + \vskip 1em + {\Large \textsf{$subtitle$}} + $endif$ + \vskip 2em + \noindent {\Large \textsf{$for(author)$$author$$sep$, $endfor$} \vskip 0.6em \textsf{$date$}} + \vfill +} +$else$ +{ + \setstretch{1.4} + \vfill + \noindent {\huge \textbf{\textsf{$title$}}} + $if(subtitle)$ + \vskip 1em + {\Large \textsf{$subtitle$}} + $endif$ + \vskip 2em + \noindent {\Large \textsf{$for(author)$$author$$sep$, $endfor$}} + \vfill +} +$endif$ + +$if(titlepage-logo)$ +\noindent +\includegraphics[width=$if(logo-width)$$logo-width$$else$35mm$endif$, left]{$titlepage-logo$} +$endif$ + +$if(titlepage-background)$ +$else$ +\textsf{$date$} +$endif$ +\end{flushleft} +\end{titlepage} +\restoregeometry +\pagenumbering{arabic} +$endif$ +$endif$ + +%% +%% end titlepage +%% + +$if(has-frontmatter)$ +\frontmatter +$endif$ +$if(title)$ +$if(beamer)$ +\frame{\titlepage} +$endif$ +$if(abstract)$ +\begin{abstract} +$abstract$ +\end{abstract} +$endif$ +$endif$ + +$if(first-chapter)$ +\setcounter{chapter}{$first-chapter$} +\addtocounter{chapter}{-1} +$endif$ + +$for(include-before)$ +$include-before$ + +$endfor$ +$if(toc)$ +$if(toc-title)$ +\renewcommand*\contentsname{$toc-title$} +$endif$ +$if(beamer)$ +\begin{frame}[allowframebreaks] +$if(toc-title)$ + \frametitle{$toc-title$} +$endif$ + \tableofcontents[hideallsubsections] +\end{frame} +$if(toc-own-page)$ +\newpage +$endif$ +$else$ +{ +$if(colorlinks)$ +\hypersetup{linkcolor=$if(toccolor)$$toccolor$$else$$endif$} +$endif$ +\setcounter{tocdepth}{$toc-depth$} +\tableofcontents +$if(toc-own-page)$ +\newpage +$endif$ +} +$endif$ +$endif$ +$if(lof)$ +\listoffigures +$endif$ +$if(lot)$ +\listoftables +$endif$ +$if(linestretch)$ +\setstretch{$linestretch$} +$endif$ +$if(has-frontmatter)$ +\mainmatter +$endif$ +$body$ + +$if(has-frontmatter)$ +\backmatter +$endif$ +$if(natbib)$ +$if(bibliography)$ +$if(biblio-title)$ +$if(has-chapters)$ +\renewcommand\bibname{$biblio-title$} +$else$ +\renewcommand\refname{$biblio-title$} +$endif$ +$endif$ +$if(beamer)$ +\begin{frame}[allowframebreaks]{$biblio-title$} + \bibliographytrue +$endif$ + \bibliography{$for(bibliography)$$bibliography$$sep$,$endfor$} +$if(beamer)$ +\end{frame} +$endif$ + +$endif$ +$endif$ +$if(biblatex)$ +$if(beamer)$ +\begin{frame}[allowframebreaks]{$biblio-title$} + \bibliographytrue + \printbibliography[heading=none] +\end{frame} +$else$ +\printbibliography$if(biblio-title)$[title=$biblio-title$]$endif$ +$endif$ + +$endif$ +$for(include-after)$ +$include-after$ + +$endfor$ +\end{document} diff --git a/5.0/templates/header-eisvogel.tex b/5.0/templates/header-eisvogel.tex new file mode 100644 index 0000000..e372e1b --- /dev/null +++ b/5.0/templates/header-eisvogel.tex @@ -0,0 +1,7 @@ + +\hypersetup{colorlinks=false, + allbordercolors={0 0 0}, + pdfborderstyle={/S/U/W 1}} + +\newcommand*{\escape}[1]{\texttt{\textbackslash#1}} +\renewcommand{\paragraph}[1]{\underline{#1}} diff --git a/5.0/templates/reference.docx b/5.0/templates/reference.docx new file mode 100644 index 0000000..6cee38f Binary files /dev/null and b/5.0/templates/reference.docx differ diff --git a/5.0/tools/cyclonedx.py b/5.0/tools/cyclonedx.py new file mode 100644 index 0000000..a92e296 --- /dev/null +++ b/5.0/tools/cyclonedx.py @@ -0,0 +1,124 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- +"""CycloneDX converter for TCASVS. + +Converts the TCASVS JSON into CycloneDX Standards format (spec 1.6). + +Adapted from the ASVS CycloneDX converter. +Copyright (c) 2024 OWASP Foundation +Licensed under MIT. See tcasvs.py for full license text. +""" + +import json +import datetime +import uuid + + +class CycloneDX: + """Convert TCASVS structured JSON to CycloneDX 1.6 Standards format.""" + + def __init__(self, tcasvs_json_str): + self.tcasvs = json.loads(tcasvs_json_str) + + self.bom = { + "bomFormat": "CycloneDX", + "specVersion": "1.6", + "serialNumber": f"urn:uuid:{uuid.uuid4()}", + "version": 1, + "metadata": { + "timestamp": datetime.datetime.now() + .astimezone() + .replace(microsecond=0) + .isoformat(), + "licenses": [ + { + "license": { + "id": "CC-BY-SA-4.0", + "url": "https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt", + } + } + ], + "supplier": { + "name": "OWASP Foundation", + "url": ["https://owasp.org"], + }, + }, + "declarations": {"standards": [{}]}, + } + + standard = self.bom["declarations"]["standards"][0] + bom_ref = f"{self.tcasvs['ShortName']}-{self.tcasvs['Version']}" + standard["bom-ref"] = bom_ref + standard["name"] = self.tcasvs["Name"] + standard["version"] = self.tcasvs["Version"] + standard["description"] = self.tcasvs["Description"] + standard["owner"] = self.tcasvs["Name"] + + requirements = [] + l1_reqs = [] + l2_reqs = [] + l3_reqs = [] + + for chapter in self.tcasvs.get("Requirements", []): + chapter_req = self._convert_requirement(chapter, None) + requirements.append(chapter_req) + for section in chapter.get("Items", []): + section_req = self._convert_requirement(section, chapter_req["bom-ref"]) + requirements.append(section_req) + for item in section.get("Items", []): + item_req = self._convert_requirement(item, section_req["bom-ref"]) + requirements.append(item_req) + # Determine level + if item.get("L1", {}).get("Required"): + l1_reqs.append(item_req["bom-ref"]) + elif item.get("L2", {}).get("Required"): + l2_reqs.append(item_req["bom-ref"]) + elif item.get("L3", {}).get("Required"): + l3_reqs.append(item_req["bom-ref"]) + + standard["requirements"] = requirements + standard["levels"] = [ + { + "bom-ref": "level-1", + "identifier": "Level 1", + "description": "Minimum security baseline for all thick client applications.", + "requirements": l1_reqs, + }, + { + "bom-ref": "level-2", + "identifier": "Level 2", + "description": "Standard security for applications handling sensitive data.", + "requirements": l2_reqs, + }, + { + "bom-ref": "level-3", + "identifier": "Level 3", + "description": "Maximum security for critical applications in adversarial environments.", + "requirements": l3_reqs, + }, + ] + + def _convert_requirement(self, item, parent_ref): + """Convert a chapter/section/requirement to CycloneDX requirement format.""" + req = { + "bom-ref": item.get("Shortcode", ""), + "identifier": item.get("Shortcode", ""), + "title": item.get("Name", item.get("Description", "")), + } + if "Description" in item: + req["text"] = item["Description"] + if parent_ref: + req["parent"] = parent_ref + if "CWE" in item and item["CWE"]: + req["externalReferences"] = [ + { + "type": "reference", + "url": f"https://cwe.mitre.org/data/definitions/{cwe}.html", + } + for cwe in item["CWE"] + ] + return req + + def to_json(self): + """Export CycloneDX BOM as JSON string.""" + return json.dumps(self.bom, indent=2, ensure_ascii=False) diff --git a/5.0/tools/export.py b/5.0/tools/export.py new file mode 100644 index 0000000..68f83d3 --- /dev/null +++ b/5.0/tools/export.py @@ -0,0 +1,49 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- +"""Export TCASVS requirements to various formats (JSON, CSV, XML, CycloneDX). + +Usage: + python export.py --format json --language en + python export.py --format csv --language en + python export.py --format xml --language en + python export.py --format cdx_json --language en + python export.py --verify-only --format json --language en + +Copyright (c) 2024 OWASP Foundation +Licensed under MIT. See tcasvs.py for full license text. +""" + +import argparse +from tcasvs import TCASVS +from cyclonedx import CycloneDX + +parser = argparse.ArgumentParser(description="Export TCASVS requirements.") +parser.add_argument( + "--format", + choices=["json", "json_flat", "xml", "csv", "cdx_json"], + default="json", +) +parser.add_argument("--language", default="en") +parser.add_argument("--verify-only", action="store_true") + +args = parser.parse_args() + +m = TCASVS(args.language) + +if args.verify_only: + if args.format == "csv": + print(m.verify_csv(m.to_csv())) + else: + print(m.verify_json(m.to_json())) +else: + if args.format == "csv": + print(m.to_csv()) + elif args.format == "xml": + print(m.to_xml()) + elif args.format == "json_flat": + print(m.to_json_flat()) + elif args.format == "cdx_json": + cdx = CycloneDX(m.to_json()) + print(cdx.to_json()) + else: + print(m.to_json()) diff --git a/5.0/tools/install_deps.sh b/5.0/tools/install_deps.sh new file mode 100644 index 0000000..b7ccd4a --- /dev/null +++ b/5.0/tools/install_deps.sh @@ -0,0 +1,22 @@ +#!/bin/bash +# Install dependencies for TCASVS document generation. + +set -e + +echo "Installing TCASVS build dependencies..." + +# System packages +if command -v apt-get &>/dev/null; then + sudo apt-get update -qq + sudo apt-get install -y pandoc python3 python3-pip texlive-xetex +elif command -v brew &>/dev/null; then + brew install pandoc python3 + brew install --cask mactex-no-gui +else + echo "Please install pandoc, python3, and texlive-xetex manually." +fi + +# Python packages +pip3 install --user dicttoxml2 + +echo "Done. Run 'make' from the 5.0/ directory to build all outputs." diff --git a/5.0/tools/tcasvs.py b/5.0/tools/tcasvs.py new file mode 100644 index 0000000..57fa305 --- /dev/null +++ b/5.0/tools/tcasvs.py @@ -0,0 +1,247 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- +"""TCASVS document parser and converter class. + +Adapted from the ASVS parser by Bernhard Mueller, Jonny Schnittger, and Josh Grossman. +Modified for the TCASVS table format (| V1.2.3 | Description | Level | CWE | Source |). + +Copyright (c) 2024 OWASP Foundation + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. +""" + +import os +import re +import json +import csv +from xml.sax.saxutils import escape +from dicttoxml2 import dicttoxml + +try: + from StringIO import StringIO +except ImportError: + from io import StringIO + + +class TCASVS: + """Parser for TCASVS markdown files in ASVS 5.0.0 table format.""" + + def __init__(self, language): + self.language = language + self.standard = { + "Name": "Thick Client Application Security Verification Standard", + "ShortName": "TCASVS", + "Version": "", + "Description": ( + "The OWASP Thick Client Application Security Verification Standard " + "(TCASVS) provides a basis for testing thick client application technical " + "security controls and provides developers with a list of requirements " + "for secure development." + ), + "Requirements": [], + } + self.flat_requirements = [] + + self._parse_version() + self._parse_chapters() + + def _parse_version(self): + """Extract version from the Frontispiece file.""" + frontispiece = os.path.join(self.language, "0x01-Frontispiece.md") + version_regex = re.compile(r"Version\s+(([\d.]+){3})") + if os.path.exists(frontispiece): + with open(frontispiece, encoding="utf8") as f: + for line in f: + m = version_regex.search(line) + if m: + self.standard["Version"] = m.group(1) + break + + def _parse_chapters(self): + """Parse all chapter files matching the 0xNN-V pattern.""" + # Regex for the TCASVS table format: + # | V1.2.3 | Description text | 1 | 123 | TASVS | + req_regex = re.compile( + r"^\|\s*V([\d.]+)\s*\|" # ID (e.g., V1.2.3) + r"\s*(.*?)\s*\|" # Description + r"\s*([123]?)\s*\|" # Level (1, 2, 3, or blank) + r"\s*([0-9,\s]*)\s*\|" # CWE + ) + + chapter_heading_regex = re.compile(r"^#\s+V(\d+)\s+(.*)") + section_regex = re.compile(r"^##\s+V(\d+)\.(\d+)\s+[—–-]\s+(.*)") + # Also match section headings without dash: ## V2.1 Section Name + section_regex_alt = re.compile(r"^##\s+V(\d+)\.(\d+)\s+(.*)") + filename_regex = re.compile(r"0x\d{2}-(V(\d+))-(.*)") + + for file in sorted(os.listdir(self.language)): + if not re.match(r"0x\d{2}-V", file): + continue + + m = filename_regex.search(file) + if not m: + continue + + chapter = { + "Shortcode": m.group(1), + "Ordinal": int(m.group(2)), + "ShortName": m.group(3).replace("-", " "), + "Name": "", + "Items": [], + } + + current_section = None + + with open(os.path.join(self.language, file), encoding="utf8") as f: + for line in f: + # Chapter heading + ch_match = chapter_heading_regex.match(line) + if ch_match: + chapter["Name"] = ch_match.group(2).strip() + continue + + # Section heading (with dash separator) + sec_match = section_regex.match(line) + if not sec_match: + sec_match = section_regex_alt.match(line) + if sec_match: + current_section = { + "Shortcode": f"V{sec_match.group(1)}.{sec_match.group(2)}", + "Ordinal": int(sec_match.group(2)), + "Name": sec_match.group(3).strip(), + "Items": [], + } + chapter["Items"].append(current_section) + continue + + # Requirement row + req_match = req_regex.match(line) + if req_match and current_section is not None: + req_id = req_match.group(1) + description = req_match.group(2).strip() + level_str = req_match.group(3).strip() + cwe_str = req_match.group(4).strip() + + # Derive per-level applicability from the single + # numeric Level column (lowest applicable level). + int_level = int(level_str) if level_str.isdigit() else 99 + l1 = "✓" if int_level <= 1 else "" + l2 = "✓" if int_level <= 2 else "" + l3 = "✓" if int_level <= 3 else "" + + cwe_list = [ + int(c.strip()) + for c in cwe_str.split(",") + if c.strip().isdigit() + ] + + req = { + "Shortcode": f"V{req_id}", + "Ordinal": int(req_id.rsplit(".", 1)[1]), + "Description": description, + "L1": {"Required": l1 == "✓", "Requirement": l1}, + "L2": {"Required": l2 == "✓", "Requirement": l2}, + "L3": {"Required": l3 == "✓", "Requirement": l3}, + "CWE": cwe_list, + } + + current_section["Items"].append(req) + + # Flat representation + self.flat_requirements.append({ + "chapter_id": chapter["Shortcode"], + "chapter_name": chapter["Name"], + "section_id": current_section["Shortcode"], + "section_name": current_section["Name"], + "req_id": f"V{req_id}", + "req_description": description, + "level1": l1, + "level2": l2, + "level3": l3, + "cwe": cwe_str, + }) + + self.standard["Requirements"].append(chapter) + + # --- Export methods --- + + def to_json(self): + """Export as structured JSON.""" + return json.dumps(self.standard, indent=2, ensure_ascii=False) + + def to_json_flat(self): + """Export as flat JSON array of requirements.""" + output = { + "Name": self.standard["Name"], + "ShortName": self.standard["ShortName"], + "Version": self.standard["Version"], + "requirements": self.flat_requirements, + } + return json.dumps(output, indent=2, ensure_ascii=False) + + def to_csv(self): + """Export as CSV.""" + si = StringIO() + writer = csv.writer(si) + writer.writerow([ + "chapter_id", "chapter_name", "section_id", "section_name", + "req_id", "req_description", "level1", "level2", "level3", "cwe", + ]) + for req in self.flat_requirements: + writer.writerow([ + req["chapter_id"], + req["chapter_name"], + req["section_id"], + req["section_name"], + req["req_id"], + req["req_description"], + req["level1"], + req["level2"], + req["level3"], + req["cwe"], + ]) + return si.getvalue() + + def to_xml(self): + """Export as XML.""" + xml_str = dicttoxml(self.standard, custom_root="tcasvs", attr_type=False) + return xml_str.decode("utf-8") + + def verify_json(self, json_str): + """Verify JSON output is valid and contains expected structure.""" + try: + data = json.loads(json_str) + assert "Requirements" in data + assert len(data["Requirements"]) > 0 + total_reqs = sum( + len(req["Items"]) + for chapter in data["Requirements"] + for req in chapter["Items"] + ) + return f"OK: {len(data['Requirements'])} chapters, {total_reqs} requirements" + except (json.JSONDecodeError, AssertionError, KeyError) as e: + return f"FAIL: {e}" + + def verify_csv(self, csv_str): + """Verify CSV output.""" + reader = csv.reader(StringIO(csv_str)) + rows = list(reader) + if len(rows) < 2: + return "FAIL: No data rows" + return f"OK: {len(rows) - 1} requirements" diff --git a/COMPILING.md b/COMPILING.md new file mode 100644 index 0000000..0c53a8c --- /dev/null +++ b/COMPILING.md @@ -0,0 +1,45 @@ +# Compiling the TCASVS + +## Using GitHub Actions (Recommended) + +The repository includes a GitHub Actions workflow that automatically compiles the standard into PDF format on push and pull requests. This is the recommended approach as it ensures reproducible builds. + +## Local Build + +### Prerequisites + +- Docker (recommended) OR: + - Pandoc 3.x+ + - LaTeX distribution (texlive-full or equivalent) + - Python 3.10+ + +### Using Docker + +```bash +cd 5.0 +docker run --rm -v "$(pwd):/data" pandoc/extra:latest \ + --defaults=defaults.yaml -o TCASVS_5.0.0_en.pdf +``` + +### Using Make (when available) + +```bash +make +``` + +## Output Formats + +The build system generates: +- **PDF** — For reading and distribution +- **CSV** — For importing into testing tools and spreadsheets +- **JSON** — For programmatic consumption and tooling integration + +## Folder Structure + +``` +5.0/ +├── en/ ← Markdown source files (edit these) +├── mappings/ ← ID mapping from old TASVS to TCASVS +├── templates/ ← LaTeX and Word templates for PDF/DOCX generation +└── tools/ ← Build scripts (export.py, cyclonedx.py, etc.) +``` diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 55cd437..be25fdf 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,41 +1,63 @@ -# Contributing Guidelines +# Contributing to TCASVS -Thank you for your interest in contributing to an OWASP project. We welcome all contributions and appreciate your efforts to improve our projects. +Thank you for your interest in contributing to the OWASP Thick Client Application Security Verification Standard (TCASVS). ## Getting Started -To get started with contributing to any OWASP project, please follow these steps: +1. [Join](http://owasp.org/slack/invite) the [OWASP Slack workspace](https://owasp.slack.com) to connect with the community. +2. Review the standard in [`5.0/en/`](5.0/en/) to understand the current state. +3. Check [open issues](https://github.com/OWASP/TCASVS/issues) for tasks that need help. +4. Fork the repository and create a feature branch for your changes. -1. [Join](http://owasp.org/slack/invite) the [OWASP Slack workspace](https://owasp.slack.com) to connect with the OWASP community and get help with any questions you may have. +## How to Contribute -2. Review the [OWASP Projects](https://owasp.org/projects/) page to browse the list of OWASP projects and find a project that aligns with your interests and skills. +### Proposing New Requirements -3. Visit the project's individual page and repository to familiarize yourself with the project goals and objectives. +1. Open an issue describing the security concern and why it belongs in the TCASVS. +2. Reference relevant CWE IDs, real-world attack scenarios, or industry standards. +3. Propose a draft requirement following the format below. -4. Fork the repository and clone it to your local machine. +### Requirement Format -5. Install any necessary dependencies and set up your development environment. +All requirements must follow the ASVS 5.0.0 format conventions: -6. Make your changes and test them locally to ensure they work as expected. +```markdown +| # | Description | Level | CWE | +|---|-------------|:-----:|-----| +| V{ch}.{sec}.{item} | Verify that... | 1 | {CWE-ID} | +``` -7. Submit a pull request with your changes. +- **IDs** follow `V{chapter}.{section}.{item}` numbering (e.g., V1.2.3) +- **Descriptions** start with "Verify that..." +- **Level** is the lowest level at which the requirement applies (`1`, `2`, or `3`) +- **CWE** maps each requirement to a weakness identifier -## Pull Request Guidelines +### Level Definitions -Before submitting a pull request, please make sure: +- **L1** — Baseline: applicable to all thick client applications +- **L2** — Standard: for applications handling sensitive data +- **L3** — Advanced: for applications in hostile environments or high-security contexts -1. Your changes are consistent with the project's goals and objectives. +### Change Tracking -2. Your changes are well-documented and follow the project's coding standards. +When modifying requirements in a PR, include change tags in the PR description: -3. Your changes do not introduce new bugs or break existing functionality. +- `[ADDED]` — New requirement +- `[MODIFIED]` — Wording change to existing requirement +- `[MOVED]` — Requirement moved between sections/chapters +- `[REMOVED]` — Requirement deleted (must include rationale) +- `[LEVEL_CHANGED]` — Level assignment changed -4. Your changes are accompanied by tests, if applicable. +## Pull Request Guidelines -5. Your pull request includes a clear and concise description of the changes you have made. +1. Reference the related issue in your PR description. +2. Changes to requirements must include rationale. +3. Do not modify the `archive/` folder (historical reference only). +4. Run markdown lint before submitting (see `.markdownlint.jsonc`). +5. One logical change per PR — don't mix requirement changes with formatting fixes. ## Code of Conduct -We ask that all contributors to OWASP projects abide by our [Code of Conduct](https://owasp.org/www-policy/operational/code-of-conduct). This code outlines our expectations for behavior within the project community and helps us maintain a welcoming and inclusive environment for all contributors. +All contributors must abide by the [OWASP Code of Conduct](https://owasp.org/www-policy/operational/code-of-conduct). Thank you for your interest in contributing to an OWASP project. We appreciate your efforts to help us improve and grow our projects. diff --git a/MIGRATION-SUMMARY.md b/MIGRATION-SUMMARY.md new file mode 100644 index 0000000..1b9b902 --- /dev/null +++ b/MIGRATION-SUMMARY.md @@ -0,0 +1,117 @@ +# TASVS → TCASVS v5.0.0 Migration Summary + +This document summarizes the in-place restructuring of the OWASP Thick Application Security Verification Standard from its original format (TASVS) to the new ASVS 5.0.0-aligned format (TCASVS v5.0.0). + +## Requirement Flow + +```mermaid +graph LR + subgraph Old["Old TASVS — 79 requirements"] + A["ARCH
6 reqs"] + B["CONF
9 reqs"] + C["STORAGE
9 reqs"] + D["CODE
34 reqs"] + E["CRYPTO
7 reqs"] + F["NETWORK
14 reqs"] + end + + subgraph New["New TCASVS v5.0.0 — 132 requirements"] + V1["V1 Architecture
19 reqs"] + V2["V2 Build & Env
27 reqs"] + V3["V3 Data Storage
20 reqs"] + V4["V4 Code Quality
35 reqs"] + V5["V5 Cryptography
18 reqs"] + V6["V6 Network
13 reqs"] + end + + A -->|"6 kept"| V1 + B -->|"9 kept"| V2 + C -->|"8 kept"| V3 + D -->|"26 kept"| V4 + E -->|"5 kept"| V5 + F -->|"3 kept"| V6 + F -.->|"11 redistributed"| V2 + D -.->|"7 moved"| V2 + C -.->|"2 moved"| V2 + E -.->|"2 moved"| V5 +``` + +## Key Metrics + +| Metric | Value | +|--------|-------| +| Old requirements mapped | 79 (100%) | +| New requirements total | 132 | +| Gap-fill additions | 73 | +| Requirements dropped | 1 | +| Chapters completed | 6 / 6 | +| Format compliance | ASVS 5.0.0 | +| Traceability | Full ([YAML mapping](5.0/mappings/mapping_tasvs_to_tcasvs_v5.0.0.yml)) | + +## Per-Chapter Breakdown + +| Old Chapter | Old # | Action Summary | New Chapter | New # | Gap-Fills Added | +|-------------|:-----:|----------------|-------------|:-----:|:---------------:| +| TASVS-ARCH | 6 | 6 kept + 13 gap-fills | V1 Architecture & Threat Modeling | 19 | 13 | +| TASVS-CONF | 9 | 9 kept + 18 gap-fills | V2 Build, Deployment & Environment | 27 | 18 | +| TASVS-STORAGE | 9 | 8 kept, 2 moved to V2 + 12 gap-fills | V3 Data Storage & Protection | 20 | 12 | +| TASVS-CODE | 34 | 26 kept, 7 moved to V2, 1 dropped + 9 gap-fills | V4 Code Quality & Exploit Mitigation | 35 | 9 | +| TASVS-CRYPTO | 7 | 5 kept, 2 reorganized + 11 gap-fills | V5 Cryptography | 18 | 11 | +| TASVS-NETWORK | 14 | 3 kept, 11 moved to other chapters + 10 gap-fills | V6 Network Communication | 13 | 10 | +| **Total** | **79** | | | **132** | **73** | + +## Directory Structure: Before → After + +``` +BEFORE (old TASVS) AFTER (TCASVS v5.0.0) +───────────────────── ──────────────────── +document/ 5.0/ +└── 1.0/ ├── en/ + ├── 01-Foreword.md │ ├── 0x00-Header.yaml + ├── 02-Preface.md │ ├── 0x01-Frontispiece.md + ├── 03-Using-TASVS.md │ ├── 0x02-Preface.md + ├── 04-TASVS-ARCH.md │ ├── 0x03-Using-TCASVS.md + ├── 05-TASVS-CONF.md │ ├── 0x10-V1-Architecture-and-Threat-Modeling.md + ├── 06-TASVS-CODE.md │ ├── 0x11-V2-Build-Deployment-and-Environment-Hardening.md + ├── 07-TASVS-CRYPTO.md │ ├── 0x12-V3-Data-Storage-and-Protection.md + ├── 08-TASVS-NETWORK.md │ ├── 0x13-V4-Code-Quality-and-Exploit-Mitigation.md + └── 09-TASVS-STORAGE.md │ ├── 0x14-V5-Cryptography.md + │ ├── 0x15-V6-Network-Communication.md +(no appendices, no tooling, │ ├── 0x90-Appendix-A_Glossary.md + no build pipeline, no mappings) │ ├── 0x91-Appendix-B_References.md + │ └── 0x92-Appendix-C_Contributors.md + ├── mappings/ + │ └── mapping_tasvs_to_tcasvs_v5.0.0.yml + ├── tools/ + │ ├── tcasvs.py + │ ├── export.py + │ ├── cyclonedx.py + │ └── install_deps.sh + ├── templates/ + │ ├── eisvogel.tex + │ ├── header-eisvogel.tex + │ └── reference.docx + ├── Makefile + └── generate-all.sh + archive/ + └── 1.0-original-tasvs/ ← old content preserved +``` + +## Tooling & CI Delivered + +| Artifact | Purpose | +|----------|---------| +| `5.0/tools/tcasvs.py` | Parse chapters, validate format, extract requirements | +| `5.0/tools/export.py` | Export to JSON and CSV | +| `5.0/tools/cyclonedx.py` | Generate CycloneDX BOM for compliance tooling | +| `5.0/Makefile` + `generate-all.sh` | Multi-format document generation (PDF, DOCX, JSON, CSV) | +| `.github/workflows/main.yml` | CI pipeline: lint, parse, export on every push | +| `5.0/mappings/mapping_tasvs_to_tcasvs_v5.0.0.yml` | Full old-to-new ID traceability (142 entries) | + +## What Happens Next + +1. Review this branch (`restructure/v5-format`) +2. Merge to `main` after approval +3. Run a markdown lint pass on chapter files +4. Rename the GitHub repository to `TCASVS` (in-repo references already updated to the new slug) +5. Announce the v5.0.0 restructuring to the OWASP community diff --git a/README.md b/README.md index 13da321..e6c824f 100644 --- a/README.md +++ b/README.md @@ -1,65 +1,60 @@ - # OWASP Thick Client Application Security Verification Standard (TASVS) -[![Downloads](https://img.shields.io/github/downloads/owasp/www-project-thick-client-application-security-verification-standard/total?logo=github&logoColor=white&style=flat-square)](https://github.com/owasp/www-project-thick-client-application-security-verification-standard/releases) -[![GitHub contributors](https://img.shields.io/github/contributors/owasp/www-project-thick-client-application-security-verification-standard)](https://github.com/owasp/www-project-thick-client-application-security-verification-standard/graphs/contributors) -[![GitHub issues](https://img.shields.io/github/issues/owasp/www-project-thick-client-application-security-verification-standard)](https://github.com/owasp/www-project-thick-client-application-security-verification-standard/issues) -[![GitHub pull requests](https://img.shields.io/github/issues-pr/owasp/www-project-thick-client-application-security-verification-standard)](https://github.com/owasp/www-project-thick-client-application-security-verification-standard/pulls) -[![GitHub license](https://img.shields.io/github/license/owasp/www-project-thick-client-application-security-verification-standard)](https://github.com/owasp/www-project-thick-client-application-security-verification-standard/blob/main/LICENSE) +# OWASP Thick Client Application Security Verification Standard (TCASVS) +[![Downloads](https://img.shields.io/github/downloads/owasp/TCASVS/total?logo=github&logoColor=white&style=flat-square)](https://github.com/owasp/TCASVS/releases) +[![GitHub contributors](https://img.shields.io/github/contributors/owasp/TCASVS)](https://github.com/owasp/TCASVS/graphs/contributors) +[![GitHub issues](https://img.shields.io/github/issues/owasp/TCASVS)](https://github.com/owasp/TCASVS/issues) +[![GitHub pull requests](https://img.shields.io/github/issues-pr/owasp/TCASVS)](https://github.com/owasp/TCASVS/pulls) +[![CC BY-SA 4.0](https://img.shields.io/badge/License-CC%20BY--SA%204.0-blue.svg)](https://creativecommons.org/licenses/by-sa/4.0/) - ## Introduction -The OWASP Thick Client Application Security Verification Standard (TASVS) Project aims to establish an open standard for securing thick client applications. This project provides a comprehensive framework for designing, building, and testing technical application security controls. -The TASVS Project fills the gap between the [OWASP Application Security Verification Standard (ASVS)](https://github.com/OWASP/ASVS) for web applications and the [Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs). While the MASVS can be applied to thick client testing, it is not an ideal fit. The TASVS Project seeks to create a more suitable standard for these scenarios. +The OWASP Thick Client Application Security Verification Standard (TCASVS) provides a comprehensive set of security requirements for designing, building, and testing thick client applications — desktop software, native applications, and other locally-executed programs that operate outside a browser sandbox. -## Project Leaders and Working Group - -The project is mainly maintained by a single project leader [Dave Hanson](https://github.com/JeffreyShran). However he is heavily supported by his active AppSec team at Bentley Systems who include [Samuel Aubert](https://github.com/matreurai), [Einaras Bartkus](https://github.com/eb-bsi), [Thomas Chauchefoin](https://www.linkedin.com/in/thomaschauchefoin), and [John Cotter](https://www.linkedin.com/in/john-cotter-40338612/). - -The project is also supported by the OWASP community and the OWASP Foundation. Special, thanks to [Starr Brown](https://github.com/mamicidal) for her support in her capacity as Director of Projects. - -## Roadmap - -The first public version that was suitable for use was released in September 2024. The project is in the process of refining the standard and adding more content. +The TCASVS fills the gap between the [OWASP Application Security Verification Standard (ASVS)](https://github.com/OWASP/ASVS) for web applications and the [Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs). While the MASVS can be applied to thick client testing, it is not an ideal fit. The TCASVS provides a standard purpose-built for thick client scenarios. -As we mature, we will be looking to create a more structured approach to the roadmap. As with most activities we will allow ourselves to be steered by the work completed by the [ASVS project](https://github.com/OWASP/ASVS/wiki/Roadmap-to-version-5.0) to find that strucutre. +## Latest Stable Version — 5.0.0 -In the `utils\Convert-TASVS-Excel` directory, there is a script that can be used to populate an Excel template with the TASVS checklist. This is a useful tool for applying the standard in a practical way. It is not fully release ready yet, but can be used in a pinch. I will endevour to update it over time, for now grab the Excel file that will be named something like `TASVS_v1.6.xlsx`. +The standard source is available in the [`5.0/en/`](5.0/en/) folder. It includes 6 chapters covering 130+ security requirements across three verification levels. -## Contributing +| Chapter | Title | +|---------|-------| +| V1 | [Architecture and Threat Modeling](5.0/en/0x10-V1-Architecture-and-Threat-Modeling.md) | +| V2 | [Build, Deployment, and Environment Hardening](5.0/en/0x11-V2-Build-Deployment-and-Environment-Hardening.md) | +| V3 | [Data Storage and Protection](5.0/en/0x12-V3-Data-Storage-and-Protection.md) | +| V4 | [Code Quality and Exploit Mitigation](5.0/en/0x13-V4-Code-Quality-and-Exploit-Mitigation.md) | +| V5 | [Cryptography](5.0/en/0x14-V5-Cryptography.md) | +| V6 | [Network Communication](5.0/en/0x15-V6-Network-Communication.md) | -The project is looking for contributors to help with the following tasks: +## Project Leaders and Working Group -- Getting the word out about the project. If you do ntohing else, please share this project with your network. -- Review and provide feedback on the current standard. -- Create new control objectives. -- Update existing control group definitions, particularly those ones that: - - might benefit from code examples and - - those that could be elaborated on further in simpler terms to make it more accessible to juniors in our field and developers with less security experience. +The project is led by [Dave Hanson](https://github.com/JeffreyShran) and [Samuel Aubert](https://github.com/matreurai), supported by some former and other active AppSec team members at Bentley Systems: [Einaras Bartkus](https://github.com/eb-bsi), [Thomas Chauchefoin](https://www.linkedin.com/in/thomaschauchefoin), and [John Cotter](https://www.linkedin.com/in/john-cotter-40338612/). -> If you are interested in contributing, please review the [Contributing Guidelines](CONTRIBUTING.md) and [Code of Conduct](CODE_OF_CONDUCT.md) documents. +The project is also supported by the OWASP community and the OWASP Foundation. Special thanks to [Starr Brown](https://github.com/mamicidal) for her support in her capacity as Director of Projects. ## Standard Objectives -The requirements were developed with the following objectives in mind and are taken from the web ASVS project: https://github.com/OWASP/ASVS/blob/master/README.md#standard-objectives +- Help organizations adopt or adapt a high quality secure coding standard for thick client applications. +- Help architects and developers build secure thick client software by designing and building security in, and verifying that controls are in place and effective. +- Help security reviewers use a comprehensive, consistent, high quality standard for thick client security assessments, code reviews, and penetration testing. +- Provide a framework for procurement and vendor assessment of thick client application security. -* Help organizations adopt or adapt a high quality secure coding standard. -* Help architects and developers build secure software by designing and building security in, and verifying that they are in place and effective by the use of unit and integration tests that implement tests. -* Help security reviewers use a comprehensive, consistent, high quality standard for hybrid code reviews, secure code reviews, peer code reviews, retrospectives, and work with developers to build security unit and integration tests. It is even possible to use this standard for penetration testing at Level 1 +## Contributing -## Special thanks to our contributers +Please [log issues](https://github.com/OWASP/TCASVS/issues) if you find bugs or have ideas. We welcome pull requests based on discussion in issues. -The OWASP Thick Client Application Security Verification Standard (TASVS) Project would like to thank the following contributors for their support and dedication to the project: +See [CONTRIBUTING.md](CONTRIBUTING.md) for detailed contribution guidelines. - - +## Contributors + + + ## Sponsors
- Bentley Systems + Bentley Systems
Bentley is the leading provider of infrastructure engineering software, advancing infrastructure for better quality of life and sustainability. @@ -71,16 +66,14 @@ The OWASP Thick Client Application Security Verification Standard (TASVS) Projec ## Star History -[![Star History Chart](https://api.star-history.com/svg?repos=OWASP/www-project-thick-client-application-security-verification-standard&type=Date)](https://star-history.com/#OWASP/www-project-thick-client-application-security-verification-standard&Date) +[![Star History Chart](https://api.star-history.com/svg?repos=OWASP/TCASVS&type=Date)](https://star-history.com/#OWASP/TCASVS&Date) ## License -The entire project content is under the [Creative Commons Attribution-ShareAlike 4.0 International License][cc-by-sa]. - -## Related +The entire project content is under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). -Here are some related projects: -> please open an issue if you would like to have your project listed here. +## Related Projects - [OWASP Application Security Verification Standard (ASVS)](https://github.com/OWASP/ASVS) -- [OWASP Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs) \ No newline at end of file +- [OWASP Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs) +- [OWASP Software Assurance Maturity Model (SAMM)](https://github.com/OWASP/samm) \ No newline at end of file diff --git a/SECURITY.md b/SECURITY.md index 5510217..d63692e 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,2 +1,22 @@ -# Reporting Issues -Contact the project leaders listed on the project webpage to report security issues \ No newline at end of file +# TCASVS Security Policy + +The TCASVS leaders and community take all security bugs seriously. We appreciate your efforts to disclose issues responsibly and will make every effort to acknowledge your contributions. + +## Reporting Guidelines + +Email Dave.hanson@owasp.org with the following information: + +1. Your name and affiliation (optional but appreciated) +2. Description of the vulnerability +3. Steps to reproduce the issue +4. Current public knowledge of this vulnerability (e.g. related CVE, security advisory, etc.) + +## Response Timeline + +- **Acknowledgement**: within 3 business days of receiving your report +- **Assessment**: we will confirm whether the finding is accepted or declined within 7 business days +- **Patch**: if accepted, we aim to publish a fix within 14 business days + +## Scope + +This policy covers the TCASVS standard content, build tooling, and CI/CD pipelines in this repository. For vulnerabilities in the OWASP website infrastructure itself, please report to the [OWASP Foundation](https://owasp.org/contact/). \ No newline at end of file diff --git a/_tab_example.md b/_tab_example.md deleted file mode 100644 index b27110b..0000000 --- a/_tab_example.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Example -layout: null -tab: true -order: 1 -tags: example-tag ---- - -## Example - -Put whatever you like here: news, screenshots, features, supporters, or remove this file and don't use tabs at all. diff --git a/document/1.0/01-Foreword.md b/archive/1.0-original-tasvs/01-Foreword.md similarity index 100% rename from document/1.0/01-Foreword.md rename to archive/1.0-original-tasvs/01-Foreword.md diff --git a/document/1.0/02-Frontispiece.md b/archive/1.0-original-tasvs/02-Frontispiece.md similarity index 100% rename from document/1.0/02-Frontispiece.md rename to archive/1.0-original-tasvs/02-Frontispiece.md diff --git a/document/1.0/03-Using_the_TASVS.md b/archive/1.0-original-tasvs/03-Using_the_TASVS.md similarity index 100% rename from document/1.0/03-Using_the_TASVS.md rename to archive/1.0-original-tasvs/03-Using_the_TASVS.md diff --git a/document/1.0/04-TASVS-ARCH.md b/archive/1.0-original-tasvs/04-TASVS-ARCH.md similarity index 100% rename from document/1.0/04-TASVS-ARCH.md rename to archive/1.0-original-tasvs/04-TASVS-ARCH.md diff --git a/document/1.0/05-TASVS-CODE.md b/archive/1.0-original-tasvs/05-TASVS-CODE.md similarity index 100% rename from document/1.0/05-TASVS-CODE.md rename to archive/1.0-original-tasvs/05-TASVS-CODE.md diff --git a/document/1.0/06-TASVS-CONF.md b/archive/1.0-original-tasvs/06-TASVS-CONF.md similarity index 100% rename from document/1.0/06-TASVS-CONF.md rename to archive/1.0-original-tasvs/06-TASVS-CONF.md diff --git a/document/1.0/07-TASVS-CRYPTO.md b/archive/1.0-original-tasvs/07-TASVS-CRYPTO.md similarity index 100% rename from document/1.0/07-TASVS-CRYPTO.md rename to archive/1.0-original-tasvs/07-TASVS-CRYPTO.md diff --git a/document/1.0/08-TASVS-NETWORK.md b/archive/1.0-original-tasvs/08-TASVS-NETWORK.md similarity index 100% rename from document/1.0/08-TASVS-NETWORK.md rename to archive/1.0-original-tasvs/08-TASVS-NETWORK.md diff --git a/document/1.0/09-TASVS-STORAGE.md b/archive/1.0-original-tasvs/09-TASVS-STORAGE.md similarity index 100% rename from document/1.0/09-TASVS-STORAGE.md rename to archive/1.0-original-tasvs/09-TASVS-STORAGE.md diff --git a/archive/README.md b/archive/README.md new file mode 100644 index 0000000..6d20930 --- /dev/null +++ b/archive/README.md @@ -0,0 +1,7 @@ +# Archive — Original TASVS Format + +This directory contains the original TASVS (Thick Application Security Verification Standard) content as published in September 2024. + +These files are preserved for historical reference only. The current standard is maintained in `5.0/en/` using the ASVS 5.0.0 format under the TCASVS name. + +**Do not edit these files.** For the active standard, see [`../5.0/en/`](../5.0/en/). diff --git a/assets/images/BentleyLOGO_BLK_type.jpg b/images/BentleyLOGO_BLK_type.jpg similarity index 100% rename from assets/images/BentleyLOGO_BLK_type.jpg rename to images/BentleyLOGO_BLK_type.jpg diff --git a/index.md b/index.md index 248c819..025f49c 100644 --- a/index.md +++ b/index.md @@ -2,25 +2,25 @@ layout: col-sidebar title: OWASP Thick Client Application Security Verification Standard -tags: example-tag +tags: tcasvs, thick-client, security-verification level: 2 type: Documentation -pitch: This project aims to fill the gap between the web ASVS and the mobile ASVS (MASVS), whilst the MASVS can be used for thick client testing it's not a perfect fit and so we hope to produce something more appropriate. +pitch: The OWASP TCASVS provides a comprehensive set of security requirements for designing, building, and testing thick client applications — desktop software, native applications, and other locally-executed programs that operate outside a browser sandbox. --- ## Introduction -The OWASP Thick Client Application Security Verification Standard (TASVS) Project aims to establish an open standard for securing thick client applications. This project provides a comprehensive framework for designing, building, and testing technical application security controls, addressing architectural concerns, secure development lifecycle, threat modeling, agile security practices, continuous integration/deployment, serverless environments, and configuration management. +The OWASP Thick Client Application Security Verification Standard (TCASVS) provides a comprehensive set of security requirements for designing, building, and testing thick client applications — desktop software, native applications, and other locally-executed programs that operate outside a browser sandbox. -The TASVS Project fills the gap between the [OWASP Application Security Verification Standard (ASVS)](https://github.com/OWASP/ASVS) for web applications and the [Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs). While the MASVS can be applied to thick client testing, it is not an ideal fit. The TASVS Project seeks to create a more suitable standard for these scenarios. +The TCASVS fills the gap between the [OWASP Application Security Verification Standard (ASVS)](https://github.com/OWASP/ASVS) for web applications and the [Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs). While the MASVS can be applied to thick client testing, it is not an ideal fit. The TCASVS provides a standard purpose-built for thick client scenarios. -## How to get it +## How to Get It -The latest PDF version of the standard can be downloaded from the [Releases](https://github.com/OWASP/www-project-thick-client-application-security-verification-standard/releases/latest) page. +The latest version of the standard can be downloaded from the [Releases](https://github.com/OWASP/TCASVS/releases/latest) page in PDF, DOCX, CSV, JSON, and CycloneDX formats. ## Project Leaders and Working Group -The project is mainly maintained by a single project leader [Dave Hanson](https://github.com/JeffreyShran). However, he is heavily supported by his active AppSec team at Bentley Systems who include [Samuel Aubert](https://github.com/matreurai), [Einaras Bartkus](https://github.com/eb-bsi), [Thomas Chauchefoin](https://www.linkedin.com/in/thomaschauchefoin), and [John Cotter](https://www.linkedin.com/in/john-cotter-40338612/). +The project is led by [Dave Hanson](https://github.com/JeffreyShran) and [Samuel Aubert](https://github.com/matreurai), supported by some former and other active AppSec team members at Bentley Systems: [Einaras Bartkus](https://github.com/eb-bsi), [Thomas Chauchefoin](https://www.linkedin.com/in/thomaschauchefoin), and [John Cotter](https://www.linkedin.com/in/john-cotter-40338612/). The project is also supported by the OWASP community and the OWASP Foundation. Special thanks to [Starr Brown](https://github.com/mamicidal) for her support in her capacity as Director of Projects. @@ -42,15 +42,15 @@ The project is looking for contributors to help with the following tasks: - might benefit from code examples and - those that could be elaborated on further in simpler terms to make it more accessible to juniors in our field and developers with less security experience. -## Special thanks to our contributors +## Special Thanks to Our Contributors -The OWASP Thick Client Application Security Verification Standard (TASVS) Project would like to thank all of our [contributors](https://github.com/OWASP/www-project-thick-client-application-security-verification-standard/graphs/contributors) for their support and dedication to the project. +The OWASP TCASVS would like to thank all of our [contributors](https://github.com/OWASP/TCASVS/graphs/contributors) for their support and dedication to the project. ## Sponsors

- Bentley Systems + Bentley Systems

diff --git a/info.md b/info.md index bd5508c..0af6e18 100644 --- a/info.md +++ b/info.md @@ -1,3 +1,3 @@ ### Thick Client Application Security Verification Standard Information * [Incubator Project](#) -* [Version 1.0.0](#) +* [Version 5.0.0](#) diff --git a/leaders.md b/leaders.md index b66cb1a..ead4424 100644 --- a/leaders.md +++ b/leaders.md @@ -1,2 +1,3 @@ ### Leaders * [Dave Hanson](mailto:Dave.hanson@owasp.org) +* [Samuel Aubert](mailto:samuel.aubert@owasp.org) diff --git a/project.owasp.yaml b/project.owasp.yaml index 2c133b2..9f5438d 100644 --- a/project.owasp.yaml +++ b/project.owasp.yaml @@ -1,22 +1,28 @@ audience: - builder + - defender + - tester leaders: - name: Dave Hanson email: Dave.hanson@owasp.org + - name: Samuel Aubert + email: samuel.aubert@owasp.org level: 2 license: - CC-BY-SA-4.0 name: OWASP Thick Client Application Security Verification Standard -pitch: The OWASP Thick Client Application Security Verification Standard (TASVS) Project aims to establish an open standard for securing thick client applications. This project provides a comprehensive framework for designing, building, and testing technical application security controls. The TASVS Project fills the gap between the OWASP Application Security Verification Standard (ASVS) for web applications and the Mobile Application Security Verification Standard (MASVS). While the MASVS can be applied to thick client testing, it is not an ideal fit. The TASVS Project seeks to create a more suitable standard for these scenarios. +pitch: The OWASP Thick Client Application Security Verification Standard (TCASVS) provides a comprehensive set of security requirements for designing, building, and testing thick client applications. It fills the gap between the OWASP ASVS for web applications and the MASVS for mobile applications, providing purpose-built requirements for desktop and native applications that execute outside a browser sandbox. repositories: - - name: www-project-thick-client-application-security-verification-standard - url: https://github.com/OWASP/www-project-thick-client-application-security-verification-standard + - name: TCASVS + url: https://github.com/OWASP/TCASVS description: OWASP Thick Client Application Security Verification Standard tags: + - TCASVS - TASVS - ASVS - MASVS - - SAMM + - thick-client + - desktop-security - OWASP type: documentation website: https://owasp.org/www-project-thick-client-application-security-verification-standard diff --git a/utils/Convert-TASVS-Excel/convert-tasvs-excel.py b/utils/Convert-TASVS-Excel/convert-tasvs-excel.py index f4086b5..2f83d30 100644 --- a/utils/Convert-TASVS-Excel/convert-tasvs-excel.py +++ b/utils/Convert-TASVS-Excel/convert-tasvs-excel.py @@ -174,7 +174,7 @@ def run(self): if __name__ == "__main__": - repo_document_root_url = "https://raw.githubusercontent.com/OWASP/www-project-thick-client-application-security-verification-standard/main/document/1.0/" + repo_document_root_url = "https://raw.githubusercontent.com/OWASP/TCASVS/main/document/1.0/" tasvs_files = [ ("04-TASVS-ARCH.md", "TASVS-ARCH"), ("05-TASVS-CODE.md", "TASVS-CODE"), @@ -188,7 +188,7 @@ def run(self): ) response = requests.get( - "https://api.github.com/repos/OWASP/www-project-thick-client-application-security-verification-standard/releases/latest" + "https://api.github.com/repos/OWASP/TCASVS/releases/latest" ) if response.status_code == 200: