1. Introduction and Scope

This document establishes the security governance policy for all operations within the organization.

The scope of this policy applies to all employees, contractors, and third parties involved in the design, development, testing, deployment, and operation of company assets, including but not limited to software & hardware products, game titles, and associated infrastructure.

2. Policy Framework and Standards

Our security program is structured around the principles outlined in the following frameworks:

2.1. Core Architectural Security Principles

All systems designed within Yutila must adhere to the foundational security principles defined by Saltzer and Schroeder (1975):

• Fail-Safe Defaults: Base access decisions on explicit permission rather than exclusion. If a system fails, it must fail into a closed, secure state.
• Complete Mediation: Every access to every object must be cryptographically or logically verified for authority.
• Least Privilege: Every program and user must operate using the minimum set of privileges necessary to complete their function.
• Open Design: System security should not depend on the ignorance of potential attackers. The mechanisms must be public; only the keys are secret.

3. Organizational Security Policies

3.1. Governance and Risk Management

The security team is responsible for reviewing and approving all security policies, managing enterprise-wide security risk, and ensuring compliance.

• Risk Assessment: All projects and products must undergo a formal security risk assessment utilizing a standardized methodology (e.g., STRIDE for threat modeling or a formally defined risk matrix) prior to launch.
• Policy Review: This policy and its associated risk assessments must be formally reviewed annually, or immediately following any major architectural shift or Critical severity incident, to ensure evolving threats are accounted for.
• Security Training: Mandatory annual security awareness and secure coding training is required for all personnel.

3.2. Access Control and Identity Management

• Principle of Least Privilege: Users must be granted only the minimum access rights necessary to perform their job duties. Access must be reviewed quarterly by the IT Operations Lead or the respective system owner to ensure permissions remain appropriate and adhere to the Principle of Least Privilege.
• Multi-Factor Authentication (MFA): MFA is mandatory for all access to development environments, source code repositories, and production systems.
• Termination: Access rights must be revoked immediately upon a member’s separation from the organization.
• Secret Management & Machine Identities: Hardcoded credentials within source code are strictly prohibited. All machine identities, API keys, and production credentials must be managed via a dedicated secrets manager (e.g., Infisical or GitHub Secrets). Committing .env files containing production secrets is banned, and automated secret scanning must be enforced in the CI/CD pipeline.
• Commit Signature Verification: To ensure the integrity and non-repudiation of all code contributions, all commits pushed to organizational repositories must be cryptographically signed using a verified SSH key. Commits that are not signed will be rejected by the CI/CD pipeline and branch protection rules.
  • Resource: Setup SSH Keys for Commit Signature

3.3. Incident Response and Business Continuity

All security incidents must be reported immediately to the Incident Commander via the designated secure channel. The Incident Commander will orchestrate the response following the documented procedures in the playbook linked below:

Cybersecurity Incident Response Playbook

3.4. Coordinated Vulnerability Disclosure (CVD)

All external vulnerability reports submitted via the Yutila repository channels or email must be handled following the OpenSSF Coordinated Vulnerability Disclosure Process.

• The Incident Commander will validate the report and establish a secure communication channel with the researcher.
• Patches must be developed in an embargoed, private environment.
• Public disclosure and security advisories will only be published simultaneously with the deployment of the remediated release.

4. Secure Development Lifecycle (SDLC) Policy

This policy outlines the mandatory security requirements for all software development projects within the organization, ensuring security is integrated throughout the development lifecycle.

Human Verification (Peer Review): Automated security scanners are supplementary and do not replace logical architectural review. Code merged into production branches requires human peer review, except under authorized “Solo Contributor” or “Emergency Merge” conditions. Bypassing human review requires the commit to be cryptographically signed and successfully pass all mandatory automated pipeline status checks (e.g., SAST, Secret Scanning, SBOM).

4.1. Quality Assurance and Security Testing

All developed software must undergo the following minimum security and quality tests:

4.2. Continuous Integration/Continuous Delivery (CI/CD) Security Requirements

All software development must utilize a CI/CD pipeline that is configured to enforce the following security steps automatically:

1. Automated Builds and Testing: The pipeline must automatically retrieve the latest source code, compile the application, and execute all mandatory Unit, Integration, SAST, and DAST tests.
2. Dependency Vulnerability Scanning: All third-party libraries and dependencies used in the project must be scanned for known vulnerabilities (e.g., against CVE databases).
3. Mandatory Pass/Fail Enforcement: The pipeline must automatically FAIL and block deployment if tests do not pass or if High/Critical vulnerabilities are detected, unless a formal Vulnerability Waiver and risk-acceptance justification is documented and approved by the Security Policy Officer.

4.3. Special Requirements for Game Development (Where Applicable)

For all software classified as games or entertainment products, the following security measures are mandatory:

• Anti-Tamper & Anti-Cheat: All multiplayer games must implement and maintain industry-standard anti-cheat and anti-tamper technologies. These solutions must be reviewed by the Security Policy Officer and subjected to adversarial validation. Validation may be conducted via internal red-teaming, structural review, or a closed-beta Coordinated Vulnerability Disclosure (CVD) process prior to any public release.
• Secure Backend Systems: All server-side logic, APIs, and services supporting the game must fully adhere to all standards and requirements defined in Section 1 and Section 2 of this policy.
• Client-Side Sensitive Data Protection: Any sensitive data stored on the client side (e.g., authentication tokens, payment information, personal data) must be protected using strong encryption and secure storage mechanisms.

4.4. Language-Specific Security Standards

To ensure memory safety and prevent language-specific vulnerabilities natively, all development must adhere strictly to established secure coding standards for the respective language:

• C: All C-based development, including the Camelot framework, must adhere to the SEI CERT C Coding Standard. Compliance is structurally enforced via the project Makefile and CI pipeline; no code shall be merged unless it compiles with -Wall -Wextra -Wpedantic -Werror, passes all unit/integration tests with Clang/GCC Sanitizers enabled (-fsanitize=address,undefined,leak), and satisfies clang-tidy static analysis using cert-* check profiles.
• (Additional language standards will be documented here prior to the adoption of new stacks in production).

4.5. Third-Party Dependency Evaluation

Integrating unverified third-party libraries introduces immediate supply chain risk. To mitigate this, all integrated third-party code and internal distributions must conform to the OpenChain ISO/IEC 5230 and ISO/IEC 18974 standards for license compliance and security.

Tiered Dependency Registry

To balance development velocity with security, the Architecture pillar maintains a tiered model for validating external Open Source Software (OSS) before adoption into the production baseline:

• Tier 1 (Inherited Trust): Dependencies from the yutila-org core registry or top-tier foundations (e.g., Linux Foundation, Apache, Google, Microsoft) with a GitHub Star count >1000 and active maintenance (commit within 6 months) are pre-validated for prototyping.
• Tier 2 (Manual Audit): New or niche dependencies require a formal “Dependency Review” issue. The Architecture pillar must evaluate the project’s security posture using the OpenSSF Concise Guide for Evaluating OSS, SAFECode Principles, and the OpenSSF Scorecard.
• Tier 3 (Blocked): Dependencies with “Copyleft” licenses (e.g., GPLv3, AGPL) for non-open Source projects or known “Critical” vulnerabilities are strictly prohibited from the production baseline.
  • Copyleft Rationale (For Non-Open Source Projects): Copyleft licenses contain viral derivative-work clauses. Statically or dynamically linking GPLv3/AGPL code into proprietary or revenue-generating Yutila projects legally triggers this clause, mandating the public release of our entire closed-source IP under the same open license. To preserve our ability to monetize software or keep specific logic proprietary, only permissive licenses (e.g., MIT, Apache 2.0, BSD-3-Clause) are authorized for integration into non-open source tracks.
  • Vulnerability Rationale: “Critical” CVSS dependencies often enable unauthenticated Remote Code Execution (RCE). Deploying these risks a container escape, exposing the centralized physical infrastructure to complete compromise.

Transitive Auditing

Prior to integration, the full dependency tree must be queried via deps.dev to identify hidden transitive vulnerabilities or abandoned sub-dependencies. Approval is contingent on the health of the entire recursive tree, not just the top-level package.

5. Telemetry and Data Policy

The collection of all telemetry and usage data must comply with the Linux Foundation’s Telemetry Data Policy and all applicable privacy laws.

• Transparency: Users must be explicitly informed about what data is collected, why it is collected, and how they can opt-out (where applicable).
• Minimization: Only the minimum necessary data required for function, performance, or security purposes shall be collected.
• Anonymization: Personal data must be anonymized or pseudonymized where technically feasible and relevant to the purpose of collection.

Appendix

To maintain a zero-cost, high-integrity CI/CD pipeline, the following open-source tools are mandated for all organizational repositories:

• SAST & Vulnerability Scanning: Trivy by Aqua Security (Apache 2.0 License)
• DAST: OWASP ZAP (Zed Attack Proxy) (Apache 2.0 License)
• Secrets Management: GitHub Actions Secrets (Native Platform Feature)
• SBOM Generation: Syft by Anchore (Apache 2.0 License)