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.

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

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.

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.

• 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

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

Cybersecurity Incident Response Playbook

In the event of a security anomaly, personnel are required to follow the established escalation path:

• Tier 1 (Individual Contributor/Developer): Initial discovery. Alert the team lead and open an internal low-priority security ticket. Do not publicize the finding.
• Tier 2 (Security Engineering Team): Triages the ticket. If validated and categorized as High or Critical severity, the team immediately hands over control to the SecOps Director.
• Tier 3 (SecOps Director): Implements containment procedures, convenes the crisis management team, and decides whether legal and executive leadership need to be involved.
• Tier 4 (Executive & Legal): Handles public vulnerability disclosure, law enforcement collaboration, and regulatory compliance reporting (e.g., data breach notifications within statutory timelines).

All external vulnerability reports must be submitted using the built-in GitHub feature for reporting security vulnerabilities (Private Vulnerability Reporting). Alternatively, reports can be submitted directly via email to yutila@atomicmail.io. The SecOps Director will validate the report and establish a secure communication channel with the researcher. We adhere to a strict 90-day deadline policy. If a reported vulnerability is not fixed within 90 days of the initial report, the researcher is permitted to publicly disclose it. Once a vulnerability is fixed, it is free to be publicly disclosed immediately. 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 or after the 90-day deadline expires.

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).

All developed software must undergo security testing governed by the formal Application Security Testing Analysis (ASTA) framework. To support our strictly zero-cost, open-source pipeline hosted entirely on a single 2013 Mac Pro server utilizing ubuntu-latest ephemeral GitHub Actions runners, ASTA operates as a bifurcated system:

• General Tools: Applied globally to all repositories. Includes Trivy (SAST/Filesystem/IaC), Gitleaks (Secrets), and Syft (SBOM).
• Domain-Specific Tools: Executed conditionally, only when the target repository contains matching language or infrastructure signatures. Includes Hadolint (Docker), Detekt (Kotlin), Find Sec Bugs (JVM bytecode), MobSF (Android binaries), Jazzer (JVM fuzzing), ZAP by Checkmarx (Web/API DAST), and OpenSSF Scorecard (public repositories only — requires GitHub GraphQL API access unavailable to the default GITHUB_TOKEN on private repositories).

To explicitly prevent hardware timeouts and runner exhaustion on the Mac Pro, tools are executed in a strict Three-Stage Pipeline. Tools will only trigger if their specific target domain is present:

• Stage 1 (Commit/PR - High Speed): Executed synchronously on every commit and pull request.
  • Tools: Gitleaks, Hadolint, Detekt.
• Stage 2 (CI/CD - Medium Speed): Executed synchronously during the core integration and build phase.
  • Tools: Trivy, Syft, Find Sec Bugs, MobSF Static Analysis.
• Stage 3 (Asynchronous/Local - High Resource): Executed asynchronously (e.g., scheduled nightly tasks) or locally. This stage must not run synchronously in standard PR actions to avoid runner exhaustion.
  • Tools: Jazzer, MobSF Dynamic Analysis, ZAP by Checkmarx.

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.

To provide continuous visibility and threat remediation, the organization relies on a Security Orchestration, Automation, and Response (SOAR) architecture:

• Wazuh (SIEM & XDR): Deployed across all hosts for continuous intrusion detection, security monitoring, and log correlation.
• General ASTA Tools (Trivy, Syft, Gitleaks): Orchestrated globally across all CI pipelines to evaluate file systems, generate SBOMs, and block hardcoded secrets.
• Domain-Specific ASTA Tools: Hadolint, Detekt, Find Sec Bugs, MobSF, Jazzer, and ZAP by Checkmarx are conditionally orchestrated based on repository signatures, providing targeted linting, static analysis, dynamic testing, and fuzzing only when their respective domains are present.
• GitHub Actions: Serves as the primary automation orchestrator, conditionally triggering Stage 1 and Stage 2 ASTA scans on pull requests based on repository domains, managing the asynchronous scheduling of Stage 3 execution, and orchestrating deployment blocks if security criteria are not met.

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.

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.

• Java: All JVM-based development must adhere to strict security boundaries. Find Sec Bugs is required for static bytecode analysis. Additionally, Jazzer is strictly mandated for fuzzing high-risk, untrusted data parsers (e.g., XML/RSS feeds).

• Kotlin: Kotlin development inherits all JVM protections (Find Sec Bugs, Jazzer) and must additionally mandate the use of Detekt to enforce architectural boundaries and linting standards.

• Android: Development for Android environments builds upon the Kotlin/Java standards. It must additionally utilize MobSF for comprehensive Android component validation.

(Additional language standards will be documented here prior to the adoption of new stacks in production).

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.

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: ZAP by Checkmarx (Zed Attack Proxy) (Apache 2.0 License)
• Secrets Management: GitHub Actions Secrets (Native Platform Feature)
• Secret Scanning: Gitleaks (MIT License)
• SBOM Generation: Syft by Anchore (Apache 2.0 License)
• Repository Security Posture (Public Repos Only): OpenSSF Scorecard (Apache 2.0 License)
• Docker Linting: Hadolint (GPL-3.0 License)
• Kotlin Static Analysis: Detekt (Apache 2.0 License)
• JVM Static Analysis: Find Sec Bugs (LGPL-3.0 License)
• Mobile Security Framework: MobSF (GPL-3.0 License)
• JVM Fuzzing: Jazzer (Apache 2.0 License)