Thank you for taking the time to report security concerns responsibly.

AsiBackbone Learning is an educational repository for practical .NET architecture, governed execution, policy-driven systems, secure application design, AI integration, and related architectural patterns.

The repository contains documentation, diagrams, exercises, executable teaching samples, and documentation/build automation. It is not a production security product, compliance certification, AI model, AGI or ASI implementation, autonomous-agent runtime, or robotics controller.

Learning is a living educational project that also preserves meaningful milestones as versioned educational releases. Those releases are archival and citation snapshots, not runtime package support lines. Security review therefore focuses primarily on the current repository state and the currently published documentation.

Security-sensitive corrections may result in documentation changes, sample-code changes, workflow hardening, dependency updates, or repository configuration changes depending on where the actual risk lives.

Versioned release records support provenance and reproducibility. They do not imply long-term security maintenance, backported corrections, runtime compatibility, or package-style support for historical Learning releases.

Stable release evidence is defined in RELEASE.md. Each stable release attaches its exact release notes, a scoped SPDX inventory of the tracked sample source and locked NuGet dependencies, and a hash manifest directly to the GitHub Release. Current-workflow releases also carry GitHub provenance attestations for those files. Temporary Actions artifacts are diagnostic copies, not the durable record.

The release SBOM is an inventory, not a vulnerability report or proof that the samples and dependencies are vulnerability-free. Code-scanning and dependency findings remain on their GitHub security surfaces.

Learning keeps its source-controlled security automation deliberately proportional to an educational repository:

• .github/dependabot.yml monitors NuGet manifests used by the local DocFX tool and executable samples, and it monitors GitHub Actions dependencies. Routine updates are scheduled, bounded, and grouped so they arrive as reviewable maintenance pull requests rather than unmanaged drift.
• .github/workflows/codeql.yml runs CodeQL analysis over the repository's C# source on relevant pull requests and pushes to main, with a periodic scheduled scan. The workflow uses least-privilege token permissions and SHA-pinned actions.

These controls create maintenance and static-analysis signals. They do not establish that Learning, its examples, or a consuming application is secure, compliant, vulnerability-free, or appropriate for a particular production risk level.

Some security controls remain repository- or organization-setting concerns rather than source-controlled workflow concerns. Secret scanning, push protection, Dependabot alerts and security updates, branch/ruleset enforcement, and related hosting controls must be verified in GitHub settings; their state cannot be inferred from committed YAML alone.

The repository-specific desired state and administrator audit/apply procedure are documented in Repository Host Security Controls and represented by eng/repository-controls/main-branch-ruleset.json.

Audit the live GitHub settings with:

./scripts/Manage-RepositorySecurityControls.ps1

The script is read-only by default. Use -Apply -WhatIf before the explicit -Apply path so repository-host mutations can be reviewed before they are made.

The committed CodeQL workflow is an advanced-setup configuration. If CodeQL default setup is currently enabled for the repository, switch CodeQL to advanced setup so GitHub does not disable the workflow or block its analysis uploads.

For the architectural reasoning behind these distinctions, see Software Supply-Chain Integrity for .NET Repositories.

Please do not place exploit details, secrets, proof-of-concept payloads, private keys, tokens, personal data, or sensitive operational information in a public Issue, pull request, Discussion, commit message, screenshot, or comment.

Preferred reporting path:

1. Open this repository's Security tab and select Report a vulnerability to use GitHub private vulnerability reporting when it is available.
2. Include a concise title and identify the affected repository area, version, branch, or commit when known.
3. Provide reproduction steps, expected behavior, actual behavior, and the practical security impact.
4. Use synthetic data and redact secrets or identifying information.
5. Allow reasonable time for review before public disclosure.

If private vulnerability reporting is unavailable, open a minimal public Issue stating only that you have a sensitive security report to share. Do not include technical details or sensitive material in that Issue.

For non-sensitive hardening suggestions, documentation corrections, or defense-in-depth improvements, a normal GitHub Issue or pull request is appropriate.

This is a community-maintained open-source project and does not promise a formal security-response SLA or fixed acknowledgment or remediation timelines.

The expected best-effort process is:

1. A maintainer reviews the report and determines whether it is a vulnerability, documentation issue, sample or template issue, workflow or dependency concern, hardening opportunity, duplicate, or out-of-scope report.
2. The maintainer may request clarification, affected-version or commit information, sanitized logs, or a reduced reproduction.
3. Confirmed concerns are addressed through code, documentation, dependency, workflow, repository-configuration, release, or advisory changes appropriate to the risk.
4. Public communication distinguishes confirmed behavior from suspected risk and avoids overstating security, compliance, legal, or operational guarantees.

Please avoid repeated public disclosure while a sensitive report is being reviewed.

When reporting a concern:

• redact passwords, secrets, tokens, private keys, certificates, connection strings, user identifiers, personal information, customer data, and regulated data;
• use synthetic examples whenever possible;
• share only the minimum information required to reproduce or understand the concern;
• clearly identify any material that remains sensitive.

Public communication should distinguish implemented controls from intended architecture, repository behavior from downstream or consuming-system behavior, and verified evidence from assumptions.

Do not describe a repository, package, template, sample, workflow, or generated application as vulnerability-free, automatically compliant, legally sufficient, tamper-proof, or production-ready solely because a documented control exists or automated checks pass.

Areas especially relevant to this repository include:

• executable teaching samples under samples/;
• examples that demonstrate policy evaluation, acknowledgment, decision receipt, scoped capability, or host-owned execution;
• AI tool-gateway examples and host-side execution boundaries;
• sample handling of secrets, credentials, tokens, connection strings, or sensitive-looking data;
• documentation that could materially misstate a security boundary or encourage unsafe production behavior;
• DocFX configuration and documentation publishing behavior;
• GitHub Actions permissions and workflow behavior;
• dependency or build-tool integrity;
• supply-chain and repository automation concerns;
• accidental disclosure of credentials, personal data, or confidential information through repository content, logs, examples, or generated artifacts.

Examples include:

• a sample that executes a consequential operation after a documented deny decision;
• a capability example that can be trivially reused, widened, or bypassed contrary to the behavior the tutorial claims to demonstrate;
• an AI tool-gateway sample that allows an unvalidated model proposal to reach host-owned execution despite documentation stating otherwise;
• documentation that instructs readers to commit real credentials or materially unsafe secret-handling practices;
• a workflow configuration that exposes a repository credential or grants unnecessarily dangerous write permissions in a way that creates a practical exploit path;
• a documentation-build or publishing issue that allows untrusted content to escape the expected build or publishing boundary;
• repository-maintained sample code that exposes sensitive data or performs an unintended external side effect by default.

Examples include:

• general disagreement with an architectural pattern when no concrete security defect is demonstrated;
• requests for a compliance, certification, legal, or security guarantee;
• vulnerabilities caused solely by a consuming application's custom implementation, infrastructure, deployment configuration, cloud policy, database security, or key-management choices;
• vulnerabilities in AsiBackbone/AsiBackbone or AsiBackbone/NetCoreApplicationTemplate that are not present in Learning material; report those to the affected repository instead;
• claims that an educational example should prevent all misuse of AI, agents, APIs, or robotics without a specific repository-level vulnerability;
• issues that exist only in a third-party fork or materially modified copy of a Learning example.

Learning examples are designed to expose architectural reasoning clearly. They intentionally omit some production complexity.

A successful sample or tutorial does not establish that a production system is secure, compliant, legally sufficient, tamper-proof, or appropriate for a particular risk level.

Production systems remain responsible for their own:

• authentication and authorization;
• policy ownership and policy correctness;
• persistence and transactional integrity;
• replay protection;
• cryptographic key custody;
• secret management;
• network and infrastructure security;
• dependency management;
• observability and incident response;
• regulatory and legal requirements;
• threat modeling and security review;
• operational execution and physical safety controls.

For governance and AI-related examples, the central teaching boundary remains:

The model may propose. The host retains execution authority.

Prompt instructions, model behavior, and tool descriptions may influence what an AI system proposes. They are not substitutes for authoritative host-side validation, policy evaluation, authorization, or execution controls.

Executable samples should remain safe teaching artifacts.

Repository-maintained samples should generally:

• use fictional or placeholder data;
• avoid real credentials, secrets, tokens, private keys, certificates, connection strings, or personal information;
• prefer deterministic local behavior;
• use mocks, fakes, simulation, or dry-run behavior for consequential external operations when practical;
• keep policy evaluation separate from side-effect execution;
• keep infrastructure credentials and execution authority host-owned;
• make important trust and execution boundaries visible;
• include tests for security-relevant architectural invariants when those invariants are central to the lesson.

A sample is not made production-ready merely because it compiles, passes tests, or demonstrates its intended architectural boundary.

If a credential, token, key, certificate, connection string, or other secret is suspected of being committed, published, logged, or exposed through repository automation:

1. Treat the secret as compromised immediately.
2. Revoke or rotate it at the issuing system before relying on repository cleanup.
3. Review relevant GitHub Actions runs, repository events, generated artifacts, and publication activity for unexpected use.
4. Remove the exposed value from the current repository state.
5. Determine whether git-history cleanup is necessary based on the sensitivity and exposure of the secret.
6. Avoid copying the exposed value into Issues, pull requests, commit messages, screenshots, or additional logs.
7. Add or improve preventive controls where practical, such as secret scanning, push protection, ignored local artifact paths, safer examples, or tighter workflow permissions.

Repository cleanup does not invalidate a credential that has already been exposed. Rotation or revocation is the primary response.

Learning frequently links to fuller implementations in other AsiBackbone organization repositories.

Security concerns in those implementations should be reported to the repository that owns the affected code:

• AsiBackbone security policy
• NetCoreApplicationTemplate security policy

If a concern exists both in Learning material and in a referenced implementation, mention that relationship in the private report so maintainers can coordinate the correction.

• README.md
• CONTRIBUTING.md
• GOVERNANCE.md
• ROADMAP.md
• LICENSING.md
• samples/README.md
• Software Supply-Chain Integrity for .NET Repositories