Version: 1.0.0 (Draft)

OSRN (Open Standard Resource Name), also known by its shorthand XRN, is a standardized format for uniquely identifying and referencing resources across different platforms, services, and organizations. Drawing inspiration from AWS ARNs while expanding their utility for broader applications.

The Open Standard Resource Name (OSRN/XRN) specification aims to establish a universal, vendor-neutral standard for resource identification across modern software development and operations. Its primary purposes are:

1. Unified Resource Identification

   • Provide a consistent way to reference any resource across different platforms, tools, and environments
   • Enable seamless integration between various development, DevOps, and monitoring tools
   • Eliminate ambiguity in resource references across team communications

2. Cross-Platform Compatibility

   • Bridge different ecosystems (cloud providers, version control systems, artifact repositories)
   • Support migration between platforms without changing resource identification logic
   • Enable multi-cloud and hybrid-cloud resource management

3. DevOps and Automation

   • Facilitate automated resource tracking and management
   • Standardize resource naming in CI/CD pipelines
   • Enable consistent logging and monitoring across different systems

4. Team Collaboration

   • Establish a common language for referring to resources across teams
   • Simplify documentation and knowledge sharing
   • Reduce confusion in cross-team communications about resources

5. System Integration

   • Provide a foundation for building tools and systems that work across platforms
   • Enable consistent resource tracking in monitoring and observability systems
   • Support building middleware and integration layers

Modern software development faces several critical challenges in resource identification and naming:

1. Inconsistent Naming Conventions

   • Each team or organization often develops their own naming conventions
   • Different platforms use different formats (Docker images, Git repositories, cloud resources)
   • No standardized way to reference the same resource across different contexts

2. Service Discovery Complexity

   • Difficulty in uniquely identifying microservices across distributed systems
   • Challenges in tracking service dependencies and relationships
   • Inconsistent service registration and discovery mechanisms

3. Cross-Platform Resource Management

   • Resources spread across multiple cloud providers and platforms
   • Different identification schemes for the same resource type on different platforms
   • Lack of unified way to reference resources in multi-cloud environments

4. DevOps Tool Integration

   • Tools using different formats to reference the same resources
   • Complexity in mapping resources between monitoring, logging, and deployment tools
   • Manual effort required to maintain resource identification across toolchains

5. Documentation and Communication

   • Ambiguity when referring to resources in documentation
   • Communication overhead between teams using different naming conventions
   • Difficulty in maintaining consistent resource references across documentation

These challenges lead to:

• Increased operational complexity
• Higher risk of configuration errors
• Communication inefficiencies
• Integration difficulties
• Reduced automation capabilities

The OSRN specification follows the fundamental principle: "Make things easier, not harder."

This principle means that when developers, teams, and organizations adopt OSRN, it should:

• Reduce complexity, not add to it
• Solve more problems than it creates
• Feel natural and intuitive to use
• Save time and effort in daily operations
• Minimize the cognitive load on teams
• Help teams work faster, not slow them down
• Simplify processes, not complicate them

Think of it like a good tool: if you have to constantly refer to documentation or struggle to use it, it's not making things easier. OSRN aims to be as natural as using a well-designed screwdriver - you pick it up and it just works, without needing a manual to understand how to hold it.

Our design goals reflect this philosophy:

1. Simplicity First

   • Easy to understand and remember format
   • Intuitive structure that follows natural resource hierarchy
   • Minimal learning curve for new team members

2. Human-Readable

   • Clear, readable format without cryptic encodings
   • Self-documenting structure
   • Easy to communicate verbally and in writing

3. Practical Implementation

   • Simple to implement in any programming language
   • Easy to validate and parse
   • Minimal overhead for existing systems

4. Flexible but Structured

   • Accommodates various resource types without complexity
   • Structured enough to maintain consistency
   • Flexible enough to adapt to different use cases

5. Tool-Friendly

   • Easy to integrate with existing tools
   • Supports automation and scripting
   • Machine-parseable without complex logic

6. Future-Proof

   • Extensible for new resource types
   • Backwards compatible by design
   • Version-aware without breaking changes

• OSRN: Open Standard Resource Name (full name)

  • The complete and formal name of our standard
  • Used in formal documentation and specifications
  • Clearly communicates the purpose: an open standard for naming resources
  • Similar to how URI (Uniform Resource Identifier) describes its purpose in its full name

• XRN: The shorthand notation for OSRN (pronounced as "X-R-N")

  • Shorter, more convenient form for daily use
  • Easier to say and write in code, logs, and casual communication
  • Pronounced by spelling out each letter: "X-R-N"
  • Similar to how people use "URL" instead of "Uniform Resource Locator"

• Resource Unique Identifier/Name

  • A string that uniquely identifies a specific resource
  • Examples:
    • GitHub repository: osrn:standard:github:global:username:repo/project
    • Docker image: osrn:standard:docker:global:organization:image/tag
    • Cloud instance: osrn:standard:aws:us-east-1:123456789:ec2/instance-id
  • Components are separated by colons (:) for easy parsing
  • Follows a consistent pattern: osrn:partition:provider:region:account:resource
  • Each component has a specific meaning and purpose in identifying the resource

Both OSRN and XRN terms refer to exactly the same standard and can be used interchangeably. Choose OSRN when clarity and formality are important, and XRN when brevity is preferred.

Both formats are valid and equivalent:

osrn::partition::provider::region::account::resource
xrn::partition::provider::region::account::resource

Each component serves a specific purpose in uniquely identifying a resource:

1. Prefix (osrn or xrn)

   • Always lowercase
   • Identifies the standard being used
   • Both forms are equivalent

2. Partition (e.g., std, gov, edu, dev, prod)

   • Separates different ecosystems and environments
   • Examples:
     • std - Default commercial/standard use
     • gov - Government resources
     • edu - Educational institutions
     • mil - Military applications
     • dev - Development environment
     • stage - Staging/Pre-production environment
     • prod - Production environment
     • test - Testing environment

3. Provider (e.g., aws, gcp, azure, github)

   • Identifies the service platform
   • Always lowercase
   • Must be registered in the standard

4. Region (e.g., us-east-1, eu-west-2, global)

   • Geographic or logical location
   • Use global for location-independent resources
   • Follow provider's region naming when applicable

5. Account (e.g., username, organization, account-id)

   • Owner or namespace of the resource
   • Format depends on the provider
   • Must be unique within the provider's scope

6. Resource (path/based/format)

   • Actual resource identifier
   • Uses forward slashes (/) as separators
   • Format varies by resource type

Resources follow provider-specific patterns for clarity and consistency:

1. Cloud Resources

   • Format: service/resource-id
   • Examples:
     • AWS EC2: osrn::standard::aws::us-east-1::123456789::ec2/i-1234567890abcdef0
     • GCP VM: osrn::standard::gcp::us-central1::project-id::compute/instance-name
     • Azure VM: osrn::standard::azure::eastus::subscription-id::vm/resource-group/vm-name

2. Version Control

   • Format: repository/project
   • Examples:
     • GitHub: osrn::standard::github::global::username::repo/project
     • GitLab: osrn::standard::gitlab::global::group::project
     • Bitbucket: osrn::standard::bitbucket::global::workspace::repo

3. Container Images

   • Format: repository/image:tag
   • Examples:
     • Docker Hub: osrn::standard::docker::global::organization::image/tag
     • GCR: osrn::standard::gcr::global::project::image:tag
     • ECR: osrn::standard::ecr::region::account::repository/image:tag

4. Package Managers

   • Format: Varies by ecosystem
   • Examples:
     • NPM: osrn::standard::npm::global::scope::package
     • Maven: osrn::standard::maven::global::group::artifact/version
     • PyPI: osrn::standard::pypi::global::package::version

5. Microservices

   • Format: service-name/instance-id
   • Examples:
     • Kubernetes: osrn::standard::kubernetes::us-east::team::service/auth-api-001
     • Service Mesh: osrn::standard::istio::prod::namespace::service/v1
     • API Gateway: osrn::standard::kong::prod::team::api/users/v2

1. General Rules

   • All components are required
   • Components are separated by double colons (::)
   • Resource paths use forward slashes (/)
   • Case-sensitive unless specified otherwise
   • No spaces allowed

2. Component-Specific Rules

   • Prefix: Must be either osrn or xrn
   • Partition: Lowercase, registered values only
   • Provider: Lowercase, registered providers only
   • Region: Provider-specific or global
   • Account: Provider-specific format
   • Resource: Provider-specific format

3. Character Set

   • Allowed: a-z, A-Z, 0-9
   • Special: - _ . / ::
   • No spaces or other special characters

1. Multi-Cloud Resource Management

   • Track resources across different cloud providers
   • Example: Listing all production databases

     osrn::prod::aws::us-east-1::123456789::rds/main-db
     osrn::prod::gcp::us-central1::project-id::sql/replica-db
     osrn::prod::azure::eastus::subscription::database/backup-db
     

2. Infrastructure as Code

   • Consistent resource referencing in templates
   • Example: Terraform module references

     resource "aws_instance" "web" {
       tags = {
         OSRN = "osrn::prod::aws::us-east-1::123456789::ec2/web-server"
       }
     }

1. CI/CD Pipeline Integration

   • Track artifacts across build stages
   • Example: Container image promotion

     osrn::dev::docker::global::myorg::app/web:latest
     osrn::stage::docker::global::myorg::app/web:v1.2.3-rc1
     osrn::prod::docker::global::myorg::app/web:v1.2.3
     

2. Dependency Management

   • Universal package references
   • Example: Cross-registry dependencies

     osrn::std::npm::global::myorg::ui-components
     osrn::std::maven::global::myorg::core-lib/2.0.0
     osrn::std::pypi::global::myorg::utils/1.0.0
     

1. Content Management

   • Track assets across storage systems
   • Example: Media file management

     osrn::prod::s3::us-east-1::content::media/videos/intro.mp4
     osrn::prod::gcs::us-central1::assets::images/logo.png
     osrn::prod::azure::global::static::documents/legal.pdf
     

2. Version Control

   • Repository and branch management
   • Example: Code references

     osrn::std::github::global::myorg::frontend/main
     osrn::std::gitlab::global::myorg::backend/feature-123
     osrn::std::bitbucket::global::myorg::shared/v2.0.0
     

1. Service Discovery

   • Microservice location and routing
   • Example: Service mesh integration

     osrn::prod::kubernetes::us-east::team::service/auth-api
     osrn::prod::istio::us-east::team::gateway/public-api
     osrn::prod::consul::us-east::team::service/payment
     

2. Monitoring and Logging

   • Universal resource identification
   • Example: Log correlation

     osrn::prod::aws::us-east-1::123456789::lambda/payment-processor
     osrn::prod::datadog::us-east-1::123456789::monitor/payment-latency
     osrn::prod::elastic::us-east-1::123456789::index/payment-logs
     

3. Security and Access Control

   • Resource-level permissions
   • Example: IAM policies

     {
       "Effect": "Allow",
       "Resource": [
         "osrn::prod::aws::us-east-1::123456789::s3/customer-data/*",
         "osrn::prod::aws::us-east-1::123456789::kms/customer-key"
       ]
     }

4. DevOps Automation

   • Cross-platform workflow automation
   • Example: Deployment pipeline

     stages:
       - build:
           artifact: osrn::dev::docker::global::myorg::app/web:${CI_COMMIT_SHA}
       - test:
           environment: osrn::test::kubernetes::us-east::team::namespace/integration
       - deploy:
           target: osrn::prod::kubernetes::us-east::team::deployment/web

Each use case demonstrates how OSRN provides:

• Consistent resource identification across platforms
• Clear environment separation
• Traceable resource relationships
• Automation-friendly format
• Platform-agnostic references

1. Regular Expression Pattern

   ^(osrn|xrn)::(std|dev|stage|prod|gov|edu)::[a-z0-9-]+::(global|[a-z0-9-]+)::[a-z0-9-]+::[a-z0-9-/._]+$

2. Component Validation

   def validate_osrn(osrn_string):
       components = osrn_string.split("::")
       if len(components) != 6:
           raise ValueError("OSRN must have exactly 6 components")
       
       prefix, partition, provider, region, account, resource = components
       
       # Validate prefix
       if prefix not in ["osrn", "xrn"]:
           raise ValueError("Invalid prefix")
       
       # Validate partition
       valid_partitions = ["std", "dev", "stage", "prod", "gov", "edu"]
       if partition not in valid_partitions:
           raise ValueError("Invalid partition")
       
       # Additional validation rules...

3. Parser Implementation

   interface OSRN {
     prefix: string;
     partition: string;
     provider: string;
     region: string;
     account: string;
     resource: string;
   }
   
   function parseOSRN(osrnString: string): OSRN {
     const parts = osrnString.split("::");
     if (parts.length !== 6) {
       throw new Error("Invalid OSRN format");
     }
   
     return {
       prefix: parts[0],
       partition: parts[1],
       provider: parts[2],
       region: parts[3],
       account: parts[4],
       resource: parts[5]
     };
   }

1. Resource Naming

   • Use lowercase for all components except where provider requires otherwise
   • Avoid special characters except -, _, ., /
   • Keep resource paths meaningful and hierarchical
   • Use semantic versioning in resource versions when applicable

2. Environment Management

   • Use partition for major environment separation (dev/stage/prod)
   • Use resource path for sub-environments
   • Example:

     osrn::dev::kubernetes::us-east::team::service/auth-api/qa
     osrn::stage::kubernetes::us-east::team::service/auth-api/perf
     osrn::prod::kubernetes::us-east::team::service/auth-api/blue
     

3. Integration Patterns

   • Store OSRN as metadata/tags in resources
   • Use OSRN in logs and metrics for correlation
   • Include OSRN in documentation and communications
   • Example:

     metadata:
       labels:
         osrn: osrn::prod::kubernetes::us-east::team::service/auth-api

4. Tool Integration

   • Implement OSRN parsers in deployment tools
   • Add OSRN validation in CI/CD pipelines
   • Use OSRN in monitoring and alerting systems
   • Example:

     def deploy_service(osrn_string):
         osrn = parse_osrn(osrn_string)
         if osrn.partition == "prod":
             require_approval()
         deploy_to_cluster(osrn.resource)

1. Access Control

   • Use OSRN patterns in IAM policies
   • Implement RBAC based on OSRN components
   • Example:

     {
       "Effect": "Allow",
       "Resource": [
         "osrn::prod::aws::*::${account}::s3/*",
         "osrn::prod::aws::*::${account}::ec2/*"
       ]
     }

2. Validation and Sanitization

   • Validate OSRN format before processing
   • Sanitize OSRN components to prevent injection
   • Example:

     def sanitize_osrn(osrn_string):
         if not OSRN_PATTERN.match(osrn_string):
             raise SecurityError("Invalid OSRN format")
         return escape_special_chars(osrn_string)

3. Audit and Compliance

   • Log OSRN usage for audit trails
   • Track OSRN changes in resource lifecycle
   • Example:

     def audit_resource_access(osrn, user, action):
         log.audit(
             resource=osrn,
             user=user,
             action=action,
             timestamp=datetime.now()
         )

4. Environment Isolation

   • Enforce strict partition boundaries
   • Prevent cross-environment access
   • Example:

     def validate_access(user_partition, resource_osrn):
         osrn = parse_osrn(resource_osrn)
         if user_partition != osrn.partition:
             raise SecurityError("Cross-partition access denied")

5. Secret Management

   • Never include secrets in OSRN strings
   • Use OSRN to reference secret locations
   • Example:

     osrn::prod::vault::us-east::team::secrets/api-keys
     osrn::prod::aws::us-east::account::secretsmanager/database
     

These guidelines ensure:

• Consistent implementation across systems
• Secure resource handling
• Proper integration patterns
• Scalable and maintainable solutions

1. AWS Resources

   osrn::prod::aws::us-east-1::123456789::ec2/web-server-01
   osrn::prod::aws::us-east-1::123456789::rds/customers-db
   osrn::prod::aws::us-east-1::123456789::lambda/payment-processor
   osrn::prod::aws::global::123456789::iam/roles/admin
   

2. Google Cloud Platform

   osrn::prod::gcp::us-central1::project-id::compute/instance-1
   osrn::prod::gcp::us-central1::project-id::sql/mysql-primary
   osrn::prod::gcp::global::project-id::storage/assets-bucket
   

3. Azure Resources

   osrn::prod::azure::eastus::subscription::vm/app-server
   osrn::prod::azure::eastus::subscription::sql/customer-db
   osrn::prod::azure::global::subscription::cdn/main
   

1. Docker Images

   osrn::dev::docker::global::myorg::api/latest
   osrn::stage::docker::global::myorg::api/v1.2.3-rc1
   osrn::prod::docker::global::myorg::api/v1.2.3
   

2. Kubernetes Resources

   osrn::prod::kubernetes::us-east::team::deployment/web-app
   osrn::prod::kubernetes::us-east::team::service/auth-api
   osrn::prod::kubernetes::us-east::team::configmap/app-config
   

1. GitHub Resources

   osrn::std::github::global::myorg::repo/main-app
   osrn::std::github::global::myorg::repo/main-app/branch/feature-123
   osrn::std::github::global::myorg::repo/main-app/tag/v1.0.0
   

2. GitLab Resources

   osrn::std::gitlab::global::myorg::project/backend
   osrn::std::gitlab::global::myorg::project/backend/pipeline/1234
   osrn::std::gitlab::global::myorg::group/team-a/project/shared-lib
   

1. NPM Packages

   osrn::std::npm::global::myorg::ui-components
   osrn::std::npm::global::myorg::ui-components/v2.1.0
   osrn::std::npm::global::myorg::core-utils/latest
   

2. Maven Artifacts

   osrn::std::maven::global::com.myorg::core-lib
   osrn::std::maven::global::com.myorg::core-lib/2.0.0
   osrn::std::maven::global::com.myorg::api-client/1.0.0-SNAPSHOT
   

1. Jenkins

   osrn::std::jenkins::global::myorg::job/main-pipeline
   osrn::std::jenkins::global::myorg::job/main-pipeline/build/123
   osrn::std::jenkins::global::myorg::agent/linux-builder
   

2. GitHub Actions

   osrn::std::github::global::myorg::workflow/ci
   osrn::std::github::global::myorg::workflow/ci/run/456
   osrn::std::github::global::myorg::secret/npm-token
   

1. Prometheus/Grafana

   osrn::prod::prometheus::us-east::team::alert/high-latency
   osrn::prod::grafana::us-east::team::dashboard/system-metrics
   osrn::prod::grafana::us-east::team::datasource/prod-prom
   

2. ELK Stack

   osrn::prod::elasticsearch::us-east::logging::index/app-logs-2023
   osrn::prod::kibana::us-east::logging::dashboard/error-tracking
   osrn::prod::logstash::us-east::logging::pipeline/main
   

1. Vault Secrets

   osrn::prod::vault::us-east::security::secret/database/credentials
   osrn::prod::vault::us-east::security::policy/read-only
   osrn::prod::vault::us-east::security::auth/github
   

2. Certificate Management

   osrn::prod::certmanager::global::security::certificate/wildcard
   osrn::prod::certmanager::global::security::issuer/letsencrypt
   osrn::prod::acm::us-east-1::123456789::certificate/api-cert
   

Each example demonstrates:

• Clear resource hierarchy
• Environment separation
• Consistent naming patterns
• Cross-platform compatibility

1. Provider Registration System

   • Centralized registry for official providers
   • Validation and verification process
   • Provider-specific format guidelines
   • Example:

     osrn::std::custom-provider::region::account::resource
     

2. Custom Components

   • Allow organization-specific components
   • Extended validation rules
   • Backward compatibility requirements
   • Example:

     osrn::custom-partition::aws::region::account::resource
     

3. Resource Type System

   • Standardized resource type definitions
   • Cross-provider type mapping
   • Type-based validation rules
   • Example:

     osrn::prod::aws::global::account::type:database/instance
     

4. Query Language

   • SQL-like syntax for resource filtering
   • Support for wildcards and pattern matching
   • Boolean operations for complex queries
   • Examples:

     # Basic queries
     osrn-query "partition=prod AND provider=aws AND resource LIKE '%db'"
     osrn-query "provider IN (aws, gcp) AND region='us-east-1'"
     
     # Complex filtering
     osrn-query "partition=prod AND (
         (provider=aws AND resource LIKE 'ec2/%') OR
         (provider=gcp AND resource LIKE 'compute/%')
     )"
     
     # Resource type filtering
     osrn-query "type=database AND status=active"
     

1. Format Versioning

   • Semantic versioning for the OSRN specification
   • Backward compatibility guarantees
   • Migration paths between versions
   • Example:

     # Version 1.0
     osrn::prod::aws::region::account::resource
     
     # Version 2.0 (hypothetical)
     osrn/v2::prod::aws::region::account::type::resource
     

2. Provider Versioning

   • Provider-specific version handling
   • Version compatibility matrix
   • Example:

     osrn::prod::aws/v2::region::account::resource
     osrn::prod::kubernetes/v1.25::region::account::resource
     

3. Resource Versioning

   • Standard version representation
   • Version range support
   • Example:

     osrn::prod::docker::global::org::image/name:v1.2.3
     osrn::prod::docker::global::org::image/name:latest
     

1. Standards Body

   • Independent governance organization
   • Community representation
   • Technical steering committee
   • RFC process for changes

2. Compliance and Certification

   • OSRN compliance certification
   • Implementation verification
   • Security assessment framework
   • Example requirements:

     compliance:
       - Valid OSRN format implementation
       - Proper security controls
       - Audit logging support
       - Documentation standards

3. Provider Guidelines

   • Provider registration process
   • Naming conventions
   • Implementation requirements
   • Example:

     provider_requirements:
       - Unique provider identifier
       - Resource format documentation
       - Reference implementation
       - Security guidelines

4. Community Development

   • Open source reference implementations
   • Community contribution guidelines
   • Plugin ecosystem
   • Example:

     community_resources:
       - Standard libraries
       - Validation tools
       - Integration frameworks
       - Migration utilities

5. Future Roadmap

   • Enhanced security features
   • Cross-platform integration tools
   • Automated compliance checking
   • Example initiatives:

     roadmap_2024:
       - Advanced validation framework
       - Cross-provider federation
       - Automated migration tools
       - Security enhancement proposals

These considerations ensure:

• Long-term sustainability
• Adaptability to new technologies
• Community-driven development
• Enterprise adoption support

1. Universal Cloud Coverage

   • OSRN is designed specifically for modern cloud-native environments
   • Supports multiple cloud providers while maintaining consistency
   • Built-in support for hybrid and multi-cloud scenarios

2. DevOps-First Design

   • Native support for CI/CD pipelines
   • Built-in environment separation
   • Consistent across development lifecycle

3. Enhanced Readability

   • Human-readable format without sacrificing machine parseability
   • Logical component ordering
   • Clear separation of concerns

4. Modern Security Model

   • Built-in support for RBAC
   • Cross-platform security policies
   • Environment-aware access control

5. Standardized Integration

   • Consistent format across all providers
   • Predictable parsing rules
   • Universal tooling support

1. Amazon Web Services. (2023). "Amazon Resource Names (ARNs)." https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html

2. Google Cloud Platform. (2023). "Resource Names." https://cloud.google.com/apis/design/resource_names

3. Microsoft Azure. (2023). "Azure Resource Naming Conventions." https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming

4. IETF. (2005). RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax." https://tools.ietf.org/html/rfc3986

5. Kubernetes SIG Architecture. (2023). "API Conventions." https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md

6. Docker. (2023). "Docker ID and Image Naming." https://docs.docker.com/docker-hub/repos/

7. NIST. (2022). "Cloud Computing Reference Architecture." https://www.nist.gov/publications/nist-cloud-computing-reference-architecture

8. Open Container Initiative. (2023). "Image Specification." https://github.com/opencontainers/image-spec

9. HashiCorp. (2023). "Resource Addressing - Terraform." https://developer.hashicorp.com/terraform/language/resources/syntax

10. OASIS. (2023). "TOSCA Simple Profile in YAML." https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/TOSCA-Simple-Profile-YAML-v1.3.html

11. W3C. (2023). "Web Architecture: Resource Names." https://www.w3.org/TR/webarch/#identification

12. Maven Central. (2023). "Guide to naming conventions." https://maven.apache.org/guides/mini/guide-naming-conventions.html

13. NPM. (2023). "Package Name Guidelines." https://docs.npmjs.com/package-name-guidelines

14. ISO/IEC. (2022). "Information Technology - Cloud Computing." ISO/IEC 17788:2014

15. CNCF. (2023). "Cloud Native Glossary." https://glossary.cncf.io/

16. Cloud Security Alliance. (2023). "Security Guidance." https://cloudsecurityalliance.org/research/guidance/

17. Open Policy Agent. (2023). "Policy Language." https://www.openpolicyagent.org/docs/latest/policy-language/

18. NIST. (2023). "Security and Privacy Controls." SP 800-53 Rev. 5