Physical AI Toolchain

The repository is public on GitHub at https://github.com/microsoft/physical-ai-toolchain. All source code, documentation, infrastructure-as-code, CI/CD workflows, issue templates, and configuration files are publicly visible. The repository settings are configured for public access with no authentication required to view, clone, or fork.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain

The project uses Git for version control, which tracks every change with author identity, timestamp, commit message, and full diff. Every file modification is recorded in the Git history. GitHub's web interface provides commit history, blame view, and diff comparison for every file. The project enforces Conventional Commits format (feat:, fix:, docs:, chore:, etc.) via contribution guidelines, providing structured change descriptions.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/commits/main
• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md

All commits are pushed to the public GitHub repository continuously. The PR-based workflow ensures that every change is visible as a pull request before and after merge. Interim work-in-progress is visible through open PRs and feature branches. GitHub's branch protection rules require PR review before merging to main, so all interim states are publicly accessible. There is no private staging or hidden development — all work flows through the public repository.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/pulls
• https://github.com/microsoft/physical-ai-toolchain/branches

Git is a distributed version control system. Every clone of the repository contains the complete history and can function independently. Contributors fork and clone the repository (as documented in CONTRIBUTING.md), work locally, and submit changes via pull requests. There is no single point of failure — any clone contains the full repository history and can serve as a restore point.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md
• https://git-scm.com/about/distributed

Every release has a unique version identifier. Four releases have been published: v0.1.0, v0.2.0, v0.3.0, and v0.4.0. Version numbers are managed by release-please automation, which reads Conventional Commits and bumps versions according to semantic versioning rules. The version is synchronized across pyproject.toml (Python package) and package.json (Node.js tooling) via release-please-config.json. Once a version is released, it is never reused or overwritten.

Evidence:
- https://github.com/microsoft/physical-ai-toolchain/tags
- https://github.com/microsoft/physical-ai-toolchain/blob/main/release-please-config.json
- https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml
- https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json

Every release is tagged in the Git repository with a "v" prefix following the pattern vMAJOR.MINOR.PATCH. Four tags exist: v0.1.0, v0.2.0, v0.3.0, v0.4.0. Tags are created by release-please automation and are cryptographically signed using Sigstore gitsign keyless signing. The verify-tag-signature.yml workflow validates that all release tags are annotated (not lightweight) and carry valid cryptographic signatures. Tag integrity is verified via git tag -v with x509 format.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/tags
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/verify-tag-signature.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md (Sigstore signing section)

CHANGELOG.md follows the Keep a Changelog format (https://keepachangelog.com/) with Semantic Versioning. Each release entry documents changes categorized by type: Added, Changed, Fixed, Documentation, Refactoring, Performance, Build System, Operations, Chores, Security, and Miscellaneous (dependency bumps). release-please automation generates changelog entries from Conventional Commit messages, ensuring every merged PR with a conventional prefix appears in the release notes. The release-please-config.json maps commit types to changelog sections. GitHub draft releases are also created by the release workflow.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CHANGELOG.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/release-please-config.json
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml (release-please job)

No CVEs have been filed against this project to date. However, the release notes infrastructure is in place to document vulnerability fixes when they occur. Security-relevant dependency bumps (e.g., werkzeug, flask, cryptography) are tracked in the CHANGELOG.md under the Miscellaneous/Dependencies section. The release-please-config.json includes a dedicated "security" changelog section mapped to the "security" commit type, ensuring any security fix committed with "security:" prefix appears prominently in release notes. Additionally, GHSA vulnerability remediations are tracked and documented (e.g., PR #271).

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CHANGELOG.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/release-please-config.json
• https://github.com/microsoft/physical-ai-toolchain/pull/271

Users can report bugs and issues via GitHub Issues, which are publicly accessible. The repository provides 7 structured issue templates in .github/ISSUE_TEMPLATE/ covering: bug reports, feature requests, documentation issues, security vulnerability reports, infrastructure requests, and more. Each template includes pre-defined labels, required fields, and guidance text. The process is documented in CONTRIBUTING.md (how to file) and SUPPORT.md (what to expect). Security vulnerabilities have a separate private reporting channel via SECURITY.md.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/issues
• https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/ISSUE_TEMPLATE
• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md

GitHub Issues serves as the project's issue tracker. It is publicly readable, searchable, and filterable. Issues support labels, milestones, and assignees for triage and tracking. The 7 issue templates apply automatic labels for categorization. Closed issues remain in the searchable archive. The tracker is integrated with PRs via GitHub's "Fixes #NNN" linking, providing traceability from bug report to fix.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/issues
• https://github.com/microsoft/physical-ai-toolchain/issues?q=is%3Aissue+is%3Aclosed

SUPPORT.md documents explicit response time commitments organized by severity tier: Security Issues — 24 hours (per SECURITY.md), Critical Bugs (data loss, security) — 1-2 business days, Major Issues (significant feature/workflow impact) — 3-5 business days, General Questions and Minor Issues — 14 business days. Issues are actively triaged by the @microsoft/edge-ai-core-dev team (CODEOWNERS). The repository shows consistent response patterns on filed issues.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/CODEOWNERS

Feature requests are accepted through GitHub Issues using the dedicated feature request issue template. Enhancement suggestions are tracked via milestones and project boards. SUPPORT.md provides response time expectations. docs/contributing/ROADMAP.md documents the project's planned direction, allowing contributors to see how enhancement requests align with project goals. The CONTRIBUTING.md explains how to propose changes and the review process for new features.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/issues
• https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/ISSUE_TEMPLATE
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/contributing/ROADMAP.md

GitHub Issues provides a permanent, public, searchable archive of all bug reports. Closed issues are retained indefinitely and remain accessible via search, filters, and direct URL. Issue history (comments, label changes, assignee changes, linked PRs, status transitions) is preserved. The archive is accessible without authentication. Issues can be filtered by label, milestone, date, author, and state (open/closed).

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/issues?q=is%3Aissue+is%3Aclosed
• https://github.com/microsoft/physical-ai-toolchain/issues

SECURITY.md (Microsoft Security Response Center template V0.0.9) provides a clear vulnerability reporting process. Security issues are reported via the Microsoft Security Response Center (MSRC) at https://msrc.microsoft.com/create-report or via email to secure@microsoft.com. The document explains what constitutes a security vulnerability, provides a PGP key for encrypted communication, references the Microsoft Bug Bounty program, and links to the Coordinated Vulnerability Disclosure (CVD) policy. This is the standard Microsoft OSS security reporting process used across thousands of Microsoft repositories.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://msrc.microsoft.com/create-report

SECURITY.md directs reporters to submit vulnerabilities privately through two channels: (1) the Microsoft Security Response Center portal at https://msrc.microsoft.com/create-report, and (2) email to secure@microsoft.com with optional PGP encryption. The reporter is explicitly instructed NOT to report security vulnerabilities through public GitHub issues. Both channels are confidential — MSRC handles reports under their Coordinated Vulnerability Disclosure (CVD) policy, keeping details private until a fix is available. PGP key download is available at https://aka.ms/security.md/msrc/pgp.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://msrc.microsoft.com/create-report
• https://www.microsoft.com/en-us/msrc/cvd

SECURITY.md commits to a 24-hour initial response for reported security vulnerabilities. SUPPORT.md also documents security issues as the highest priority tier with a 24-hour response SLA. The Microsoft Security Response Center (MSRC) backs this commitment with their global security incident response team providing follow-up through investigation, remediation, and disclosure. The MSRC has a track record of responding to reported vulnerabilities within their published timelines across all Microsoft OSS projects. Additionally, PR #233 adds explicit vulnerability remediation timeline documentation.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md
• https://github.com/microsoft/physical-ai-toolchain/pull/233

The project uses a reproducible build system. Python packages are built via hatchling (defined in pyproject.toml) with uv as the package manager. The src/training/ package builds into a wheel artifact. Node.js tooling uses npm with package.json and lockfile. Terraform infrastructure is in deploy/001-iac/ with standard terraform init/plan/apply. The setup-dev.sh and setup-dev.ps1 scripts automate development environment setup. The main.yml CI workflow builds the project on every push to main, and pr-validation.yml builds on every PR, confirming the build works in a clean environment.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json
• https://github.com/microsoft/physical-ai-toolchain/blob/main/setup-dev.sh
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml

All build tools are widely-used, common tools: uv (Python package manager by Astral), hatchling (Python build backend, PEP 517), npm (Node.js package manager), and Terraform (HashiCorp). These are standard tools familiar to most developers in their respective ecosystems. No custom or obscure build tools are required. The setup-dev.sh script documents and installs all required development tools.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (hatchling build system)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json (npm scripts)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/setup-dev.sh

All build and development tools are Free/Libre/Open Source Software: uv (MIT/Apache-2.0), hatchling (MIT), npm (Artistic-2.0), Terraform (BUSL-1.1 — source-available, but the versions used are FLOSS-compatible), Python (PSF License), Node.js (MIT), Ruff (MIT), pytest (MIT), Pester (Apache-2.0). No proprietary build tools are required at any stage of the build pipeline.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml
• https://github.com/astral-sh/uv (MIT License)
• https://github.com/pypa/hatch (MIT License)

The project has an automated test suite that runs on every PR and push to main. Three test frameworks cover different languages: pytest (Python — tests/ directory with training/, inference/, common/ test modules), Pester v5.7.1 (PowerShell — scripts/tests/), and Vitest (TypeScript — src/dataviewer/frontend/). Test execution is automated in CI via pytest-tests.yml, pester-tests.yml, and dataviewer-frontend-tests.yml, all invoked as required jobs by pr-validation.yml and main.yml. The tests/ directory includes conftest.py with shared fixtures and init.py for proper module resolution.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/tree/main/tests
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pytest-tests.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pester-tests.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/dataviewer-frontend-tests.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/tests/conftest.py

Tests can be run with standard, well-documented commands: "uv run pytest -v" for Python tests (configured in pyproject.toml [tool.pytest.ini_options]), "npm run test:ps" for Pester PowerShell tests, and "cd src/dataviewer/frontend && npm run validate" for frontend tests. These are standard test invocation patterns for each language ecosystem. No custom test harness or unusual setup is required. CI runs the same commands developers use locally.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (pytest configuration)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json (test:ps script)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pytest-tests.yml

Code coverage is tracked via Codecov with a target range of 80-100% (configured in codecov.yml). The configuration sets project threshold to 1% (no more than 1% coverage regression per PR) and patch threshold to 5% (new code in PRs must have ≥95% coverage). Branch coverage is enabled (branch: true in pyproject.toml [tool.coverage.run]). Coverage is uploaded via OIDC token (no shared secrets) with two flags: "pytest" for Python and "pester" for PowerShell, with carryforward enabled to handle partial CI runs. The codecov.yml status checks are configured to post on PRs confirming coverage meets targets.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/codecov.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (coverage configuration)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pytest-tests.yml (Codecov upload)

CI runs on every PR via pr-validation.yml (16 child jobs) and on every push to main via main.yml (14 child jobs). Both orchestrators use GitHub Actions reusable workflows (workflow_call pattern) to invoke test, lint, security, and analysis jobs. Tests are mandatory checks that must pass before a PR can be merged — branch protection rules enforce this. The release-please job in main.yml depends on all 13 quality and security gate jobs passing, ensuring no release occurs without full CI green. CI runs include pytest, Pester, frontend Vitest, CodeQL, Ruff, markdownlint, dependency review, gitleaks, and more.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pr-validation.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml
• https://github.com/microsoft/physical-ai-toolchain/actions

CONTRIBUTING.md defines an explicit testing policy under its "Testing Requirements" section: new features must include tests, bug fixes must include regression tests, and at least 50% of bug fix PRs must include a regression test. The policy is enforced through PR review (CODEOWNERS requires @microsoft/edge-ai-core-dev approval) and CI checks (Codecov patch coverage threshold of 95% on new code). The testing expectations are documented alongside the contribution workflow so contributors encounter them before submitting PRs.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/codecov.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/CODEOWNERS

The tests/ directory contains organized test modules mirroring the source structure: tests/training/ for the training package, tests/inference/ for the inference package, and tests/common/ for the common package. Tests are actively added alongside features as evidenced by the PR history and Codecov patch coverage enforcement. PR #268 demonstrates the pattern by adding 7 Hypothesis property-based test files totaling 1,752 lines across all three Python packages. The Codecov patch threshold (95%) on every PR ensures new code is tested.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/tree/main/tests
• https://github.com/microsoft/physical-ai-toolchain/blob/main/codecov.yml
• https://github.com/microsoft/physical-ai-toolchain/pull/268

CONTRIBUTING.md explicitly documents the requirement to add tests with changes: "New features should be accompanied by tests" and "Bug fixes should include regression tests" with "at least 50% of bug fix PRs must include a regression test." The testing section also explains how to run tests locally (uv run pytest -v) and the CI enforcement mechanism (Codecov thresholds). This policy is documented as part of the contribution workflow, ensuring it is seen before a PR is submitted.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md

The project enables and addresses compiler/linter warnings across all code types: Ruff (Python — 8 rule sets: E, W, F, I, UP, B, SIM, RUF) via python-lint.yml, markdownlint-cli2 (Markdown) via markdown-lint.yml, PSScriptAnalyzer (PowerShell) via powershell-lint.yml, yaml-lint (YAML) via yaml-lint.yml, cspell (spelling) run separately, ESLint (TypeScript) via dataviewer-frontend-tests.yml, and TypeScript type-checking (tsc --noEmit). All linters run in CI on both PRs and main pushes. Ruff runs both lint and format checks.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/python-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/markdown-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/powershell-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (ruff configuration)

CI enforces zero warnings as a merge gate. All linter workflows (Ruff, markdownlint, PSScriptAnalyzer, yaml-lint, ESLint, TypeScript type-check) are configured to fail on any warning. These are required checks in pr-validation.yml — a PR cannot merge with linter failures. The main.yml pipeline inherits the same checks, ensuring warnings on main are caught immediately. The 16-job pr-validation.yml gate blocks any code with warnings from reaching the main branch.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pr-validation.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/python-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/actions

Ruff is configured with 8 rule sets (E, W, F, I, UP, B, SIM, RUF) covering error detection, warnings, pyflakes, import sorting, Python upgrade suggestions, bugbear, simplification, and Ruff-specific rules — this represents a broad, strict configuration. CodeQL runs with "security-extended" and "security-and-quality" query suites, which are the maximum strictness settings. markdownlint, PSScriptAnalyzer, yaml-lint, ESLint, and TypeScript --noEmit all run with their default (strict) configurations. Combined, these tools provide extensive static analysis coverage across all major code types in the project.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (ruff rule sets)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/codeql-analysis.yml (security-extended + security-and-quality)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/python-lint.yml

The project demonstrates knowledge of secure design principles through a comprehensive STRIDE-based threat model (docs/security/threat-model.md) identifying 19 threats across 8 trust boundaries (1 Critical, 6 High, 7 Medium, 5 Low severity). The architecture follows zero-trust principles: managed identities instead of passwords, TLS 1.2+ enforced on all connections, private AKS clusters by default, network segmentation via NSGs and private endpoints. The project operates under Microsoft's OSS security governance with SECURITY.md following MSRC template V0.0.9, and docs/contributing/security-review.md provides a security review checklist for contributors.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/contributing/security-review.md

The project demonstrates awareness of common security errors through multiple mechanisms: CodeQL with security-extended and security-and-quality query suites catches OWASP Top 10 vulnerabilities (injection, XSS, path traversal, etc.) on every PR. The STRIDE threat model in docs/security/threat-model.md catalogs 19 specific threats with mitigations. Integration with Microsoft Security Response Center (MSRC) provides access to Microsoft's vulnerability intelligence. dependency-review.yml fails on moderate+ severity vulnerabilities. The project's architecture avoids common errors by design — managed identities eliminate credential storage, TLS is enforced (not optional), and the default network mode is fully private.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/codeql-analysis.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/dependency-review.yml

The project does not implement custom cryptographic algorithms. All cryptography is delegated to well-known, publicly reviewed implementations: Azure SDK (azure-identity, azure-storage) for authentication and storage encryption, TLS 1.2+ via standard libraries for transport security, and Sigstore gitsign for release tag signing. These are all industry-standard, published cryptographic mechanisms undergoing continuous public review and audit.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md (TLS 1.2+ enforcement)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md (Sigstore signing)

All cryptographic functionality is invoked via dedicated, well-maintained cryptographic libraries rather than custom implementations: Azure Identity SDK for authentication (OAuth2, managed identity tokens), Azure Storage SDK for encryption at rest/in transit, Python ssl module for TLS, and Sigstore for code signing. No project code implements its own cryptographic primitives, key derivation, or encryption algorithms.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (Azure SDK dependencies)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md

All cryptographic libraries used are FLOSS: Azure SDK for Python (MIT License — https://github.com/Azure/azure-sdk-for-python), Python's ssl module (PSF License), OpenSSL (Apache-2.0), and Sigstore (Apache-2.0 — https://github.com/sigstore). No proprietary cryptographic libraries are used anywhere in the project.

Evidence:

• https://github.com/Azure/azure-sdk-for-python/blob/main/LICENSE
• https://github.com/sigstore/gitsign/blob/main/LICENSE

The project enforces modern cryptographic key lengths. TLS 1.2+ is the minimum enforced version (configured in Terraform storage.tf for Azure Storage and across all Azure service connections), which mandates minimum 128-bit symmetric keys and 2048-bit RSA keys. Azure Managed Identity tokens use 2048-bit RSA. Sigstore gitsign uses ECDSA P-256 for release signing. No deprecated or weak key lengths (e.g., 1024-bit RSA, 56-bit DES) are used anywhere.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md (TLS 1.2+ requirement)
• https://github.com/microsoft/physical-ai-toolchain/tree/main/deploy/001-iac (Terraform infrastructure)

The project uses no broken cryptographic algorithms. The threat model in docs/security/threat-model.md confirms no use of MD4, MD5 (for security), single DES, RC4, or other deprecated algorithms. TLS 1.2+ is enforced, which excludes all known broken cipher suites. Azure SDK handles cipher suite negotiation using current best practices. SHA-256 is the minimum hash algorithm used (e.g., SHA-pinning of GitHub Actions uses SHA-256 hashes).

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml (SHA-256 pinned actions)

The default cryptographic configuration avoids known weaknesses. No SHA-1 is used for any security purpose. TLS 1.2+ with modern cipher suites is the minimum (excludes CBC-mode ciphers vulnerable to padding oracle attacks). Azure services enforce forward secrecy cipher suites by default. The dependency-review.yml workflow with fail-on-severity: moderate would catch any newly-introduced dependency with known cryptographic weaknesses.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/dependency-review.yml

All TLS connections enforced by the project use Azure services that enable Perfect Forward Secrecy (PFS) by default. Azure Front Door, App Service, Storage, and AKS ingress controllers negotiate ECDHE cipher suites that provide PFS. TLS 1.2+ (enforced in the infrastructure) mandates PFS-capable cipher suites. The project does not configure any TLS settings that would disable PFS. Azure's documentation confirms PFS support: https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-overview.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md
• https://github.com/microsoft/physical-ai-toolchain/tree/main/deploy/001-iac

The project does not store, hash, or manage user passwords in any form. All authentication is delegated to external identity providers: Azure Managed Identity for service-to-service authentication (no credentials stored), Microsoft Entra ID (Azure AD) for user authentication via OAuth2/OIDC, and Kubernetes service account tokens federated via workload identity. The Terraform infrastructure creates managed identities and federated credentials — no password fields, no credential databases, no user account tables exist anywhere in the codebase. The threat model confirms this: "managed identities (no passwords)" is an explicit design principle.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md
• https://github.com/microsoft/physical-ai-toolchain/tree/main/deploy/001-iac (managed identity resources)

The project does not directly generate cryptographic random numbers. All operations requiring cryptographic randomness are delegated to external libraries and services: Azure SDK handles authentication token generation, TLS libraries handle session key generation, and Sigstore handles signing nonce generation. No project code calls random number generators for security-sensitive purposes (key generation, nonce creation, token generation, etc.). The codebase contains no imports of cryptographic random modules (e.g., secrets, os.urandom) for security purposes.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (no crypto dependencies beyond Azure SDK)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md

The project delivers all artifacts over cryptographically-protected channels resistant to man-in-the-middle attacks. GitHub enforces HTTPS for all repository access (web, API, Git clone). PyPI packages installed via uv/pip use HTTPS by default. npm packages use HTTPS by default. Terraform providers are downloaded from registry.terraform.io over HTTPS with GPG verification. Docker/container images from nvcr.io and mcr.microsoft.com use HTTPS with content-addressable digests. GitHub Actions are SHA-pinned (95% compliance — verified by dependency-pinning-scan.yml) preventing tag-swapping attacks. Release tags are Sigstore-signed, providing cryptographic verification of release integrity.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/dependency-pinning-scan.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/verify-tag-signature.yml
• https://github.com/microsoft/physical-ai-toolchain (HTTPS-only access)

The project provides a mechanism to verify the integrity of downloaded artifacts. Release tags are cryptographically signed using Sigstore gitsign keyless signing, verified by the verify-tag-signature.yml workflow. The main.yml CI pipeline generates SBOM (Anchore SPDX-JSON format) and build provenance attestation for releases, providing a verifiable software bill of materials. GitHub Actions SHA-pinning (95% compliance) ensures CI dependencies are integrity-verified. Container images referenced in workflows use SHA digests for integrity verification. Users can verify release authenticity via git tag -v.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/verify-tag-signature.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml (SBOM + attestation)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md (Sigstore signing)

The project has multiple automated systems ensuring vulnerabilities are identified and fixed promptly. Dependabot monitors 7 ecosystem entries (pip ×4, terraform ×2, github-actions ×1) and automatically creates PRs for vulnerable dependencies on a weekly schedule. dependency-review.yml runs on every PR and fails on moderate+ severity vulnerabilities, preventing new vulnerable dependencies from being introduced. CodeQL scans for code-level vulnerabilities on every PR and push to main. Gitleaks scans for leaked secrets on every PR. SUPPORT.md documents security issues as highest priority with a 24-hour response SLA. PR #233 adds explicit vulnerability remediation timeline documentation. PR #271 demonstrates active GHSA vulnerability remediation.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/dependabot.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/dependency-review.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md
• https://github.com/microsoft/physical-ai-toolchain/pull/233
• https://github.com/microsoft/physical-ai-toolchain/pull/271

Critical vulnerabilities receive highest priority treatment. SECURITY.md and SUPPORT.md document a 24-hour response SLA for security issues. Dependabot creates automatic PRs for all critical/high severity dependency vulnerabilities. dependency-review.yml blocks PRs introducing moderate+ severity dependencies. Gitleaks-scan.yml detects leaked credentials with full history scan, uploaded as SARIF to GitHub Security tab. The project has demonstrated active vulnerability remediation — PR #271 addresses GHSA vulnerabilities, confirming the process works in practice. The automated pipeline (Dependabot → dependency-review → CODEOWNERS review → CI gate) ensures critical fixes flow through quickly.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/dependabot.yml
• https://github.com/microsoft/physical-ai-toolchain/pull/271
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/gitleaks-scan.yml

Multiple layers prevent credential leakage: (1) .gitignore excludes sensitive files: *.env, .env.local, *.tfvars, *.tfstate, *.pfx, *.publishsettings, and other credential-containing patterns. (2) gitleaks-scan.yml (Gitleaks v8.30.0 with SHA256 verification) scans the full repository history on every PR, uploading SARIF results to GitHub Security tab. (3) All CI workflows set persist-credentials: false on checkout steps, preventing credential persistence in workflow artifacts. (4) Architecture uses managed identities exclusively — no passwords or API keys exist in the codebase by design. (5) dependency-pinning-scan.yml validates 95% SHA-pinning compliance, preventing token exposure via tag-swapping attacks. (6) workflow-permissions-scan.yml enforces least-privilege permissions blocks on all workflows.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.gitignore
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/gitleaks-scan.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/dependency-pinning-scan.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/workflow-permissions-scan.yml

The project employs multiple static analysis tools integrated into CI: (1) CodeQL (codeql-analysis.yml) — GitHub's semantic code analysis engine running security-extended and security-and-quality query suites (maximum coverage) on Python code, triggered on every PR, push to main, and weekly schedule, with SARIF results uploaded to GitHub Security tab. (2) Ruff (python-lint.yml) — fast Python linter with 8 rule sets (E, W, F, I, UP, B, SIM, RUF) covering errors, warnings, pyflakes, import sorting, Python upgrade patterns, bugbear, simplification, and Ruff-specific rules, plus format checking. (3) markdownlint-cli2 for Markdown, PSScriptAnalyzer for PowerShell, yaml-lint for YAML, ESLint and TypeScript --noEmit for frontend code. All tools run as required checks in the 16-job pr-validation.yml pipeline — no code merges without passing static analysis.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/codeql-analysis.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/python-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pr-validation.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (ruff configuration)

CodeQL runs with both "security-extended" and "security-and-quality" query suites — these are GitHub's most comprehensive security query sets, specifically designed to detect common vulnerabilities including: SQL injection, cross-site scripting (XSS), path traversal, code injection, insecure deserialization, SSRF, hardcoded credentials, and other OWASP Top 10 categories. The security-extended suite goes beyond the default security queries to catch additional vulnerability patterns. Results are uploaded as SARIF to the GitHub Security tab, providing a centralized view of all detected security findings.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/codeql-analysis.yml
• https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql

Static analysis findings are fixed before release as a matter of CI enforcement. CodeQL, Ruff, and all linter checks are required jobs in pr-validation.yml — no PR can merge with static analysis failures. The main.yml pipeline runs the same checks on push to main, and the release-please job depends on all 13 quality/security gate jobs passing, meaning no release is cut unless all static analysis is clean. CodeQL SARIF results in the GitHub Security tab provide tracking of any findings that require attention.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pr-validation.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml
• https://github.com/microsoft/physical-ai-toolchain/actions

Static analysis runs on every code change: pr-validation.yml invokes CodeQL and Ruff on every pull request, main.yml invokes them on every push to main, and codeql-analysis.yml additionally runs on a weekly schedule (Sundays at 03:00 UTC) for continuous monitoring even without code changes. This means static analysis runs at minimum weekly, and in practice runs multiple times per day during active development as PRs are opened and updated. The OpenSSF Scorecard (scorecard.yml) also runs weekly, providing independent assessment of the project's security posture.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/codeql-analysis.yml (schedule + PR + push triggers)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pr-validation.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/scorecard.yml

The project employs two forms of dynamic analysis: (1) Hypothesis property-based testing (PR #268) — 7 test files totaling 1,752 lines across all three Python packages (training, inference, common), using the Hypothesis framework to generate randomized test inputs that exercise code paths not covered by deterministic unit tests. Hypothesis qualifies as dynamic analysis per the OpenSSF criterion which explicitly includes "such as testing or fuzzing." (2) OWASP ZAP DAST scanning (PR #241) — weekly Dynamic Application Security Testing scan of the dataviewer frontend, checking for runtime security vulnerabilities (XSS, injection, authentication issues, etc.) that static analysis cannot detect.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/pull/268
• https://github.com/microsoft/physical-ai-toolchain/pull/241

This criterion applies to projects with C/C++ code that should enable memory-safety checks (AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, etc.). The project contains no C or C++ code — the codebase is entirely Python, TypeScript, Terraform HCL, PowerShell, and shell scripts. Python and TypeScript are memory-safe languages. Therefore, memory-safety analyzers for compiled languages are not applicable.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain (language breakdown in GitHub sidebar)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (Python project)

Python assertions are enabled during all test execution. The pytest invocation (uv run pytest -v) does not use the -O or -OO flags, which means Python's debug is True and assert statements execute normally. Hypothesis property-based tests (PR #268) use assert statements extensively for property verification — these assertions run on every Hypothesis-generated test case (by default, 100 random inputs per test function). The pyproject.toml pytest configuration does not include any optimization flags that would disable assertions.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (pytest configuration — no -O flag)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pytest-tests.yml
• https://github.com/microsoft/physical-ai-toolchain/pull/268

Dynamic analysis findings are addressed promptly. PR #268 (Hypothesis property-based tests) discovered and fixed a real runtime bug: a RuntimeError in src/training/training/metrics.py where MLflowLogger._update() called self.writer.add_scalar() outside an active MLflow run context. This demonstrates the dynamic analysis → fix pipeline working in practice. Additionally, any OWASP ZAP findings (PR #241) would be tracked via GitHub Issues for remediation. Test failures from Hypothesis (randomized input testing) block PR merge via the pr-validation.yml CI gate.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/pull/268
• https://github.com/microsoft/physical-ai-toolchain/pull/241
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pr-validation.yml