Security Self-Assessment

CloudRepo does not currently hold SOC 2 or ISO 27001 certifications. These certifications are cost-prohibitive for a company of our size and stage. What we do instead:

• Enforce encryption at rest (AES-256), and in transit (TLS 1.2+) between your clients and CloudRepo
• Maintain strict access controls with MFA on all production and source code access
• Operate a GDPR/CCPA data-subject request process: verified access and deletion requests handled within 30 calendar days, to the scope and retention exclusions stated in our DPA
• No known security breaches in our history.

We are transparent about this gap and compensate through strong technical controls and vendor selection.

While CloudRepo manages infrastructure and application security, customers are responsible for:

• Credential management: Keeping their usernames, passwords, and API tokens secure
• Access control within their organization: Managing which team members have access to their CloudRepo repositories
• Artifact content: Customers are responsible for the security and licensing of the software they upload
• Network security: Securing their own CI/CD pipelines and build systems that connect to CloudRepo

Yes, on every plan. Members who sign in with a password can protect their account with a time-based one-time password (TOTP) from an authenticator app, and get ten single-use backup codes when they set it up. The owner can require MFA for every member who signs in with a password. If your organization uses our legacy Okta integration, only the owner can set up MFA, and MFA cannot be required for the organization.

MFA is also enforced on all internal systems:

• AWS Console: MFA required for all production access
• GitHub (source code): MFA required for all access
• All internal administrative systems require MFA

Single sign-on (SSO) via SAML and OIDC is included.

Yes. SSO via SAML and OIDC is included.

SCIM 2.0 provisioning from Okta and Microsoft Entra ID is included on every plan. Once single sign-on is on, the organization owner connects SCIM in the portal. Your identity provider then adds and updates your members, and removing or deactivating someone there after SCIM is connected ends their CloudRepo access.

• View and update account information through the CloudRepo web interface
• Request data export by contacting support or emailing privacy@cloudrepo.io
• Request data deletion under GDPR or CCPA by contacting privacy@cloudrepo.io. Deletion requests are processed within 30 calendar days, subject to the scope and retention limits in Question 17

Upon a verified deletion request, customer artifacts and repository content are deleted from Amazon S3, and GDPR/CCPA requests are processed within 30 calendar days.

What a deletion request does not remove: account and identity records (the organization record, user records, credentials, API tokens, and SSO configuration are retained; we have no automated facility to remove these today); repository metadata rows (retained with storage counters reset to zero, along with historical usage time-series); and prior copies (S3 object versioning and DynamoDB point-in-time recovery are enabled, so prior copies of deleted data remain recoverable by us for their configured retention window, and backups are rotated per AWS automated backup retention policies).

Customers can delete any repository and its contents themselves, at any time, through the portal or the API.

CloudRepo does not maintain a formal, standalone information security policy document in the traditional enterprise sense. As a small, bootstrapped team, our security practices are embedded in our operational procedures and technical controls.

What we do have: enforced technical controls (encryption, MFA, least privilege access) codified in our infrastructure-as-code (Terraform), documented security practices on our public security page, a Security Practices Document available at our Trust Center, and this vendor questionnaire response.

We recognize this is an area where we can improve and are working toward more formal documentation as the company grows.

CloudRepo uses a multi-tenant architecture with strict logical data separation per organization:

• Application layer: All data access is scoped to the authenticated user's organization. Cross-organization data access is prevented by application-level authorization checks on every request.
• Storage layer: Customer artifacts are stored in Amazon S3 using separate key prefixes per organization, ensuring logical separation of stored objects.
• Database layer: All DynamoDB records include organization identifiers, and all queries are scoped to the requesting organization.

There is no shared data surface between customer organizations.

Network segmentation is managed through multiple layers:

• AWS VPC: Production infrastructure runs in isolated Virtual Private Clouds with restrictive security group rules
• Security Groups: Inbound and outbound traffic is limited to only required ports and protocols
• DDoS protection: AWS Shield Standard provides baseline protection against common network and transport layer DDoS attacks, automatically, on the AWS services we use

Internal services communicate within the VPC and are not exposed to the public internet unless required for the application's function.

CloudRepo reviews third-party vendors periodically and replaces any that no longer meet our standards. Our full subprocessor list, with each provider's certifications where it has them, is published at /subprocessors.

CloudRepo's current practices include:

• Automated code analysis as part of the development workflow
• Pre-commit validation and testing gates in the CI/CD pipeline
• Comprehensive qualification testing before any code is deployed to production
• Dependency monitoring to identify known vulnerabilities in third-party libraries

We recommend integrating scanning tools like Snyk, Trivy, or Dependabot into CI/CD pipelines. CloudRepo supports this workflow through standard artifact upload/download APIs. Independent security researchers have identified and reported vulnerabilities through informal research, which were addressed promptly.

Encryption at rest: All artifacts in Amazon S3 are encrypted using AES-256 server-side encryption. DynamoDB encryption at rest is enabled for all tables. S3 versioning is enabled for additional protection against accidental or malicious deletion.

Encryption in transit: Every connection to CloudRepo uses TLS 1.2 or later.

Credential encryption: All passwords are hashed using PBKDF2 with BLAKE2b-512, 50,000 iterations, and a 12-byte random salt. Passwords, MFA secrets, the tokens and keys CloudRepo issues, and the upstream registry and SSO client secrets you configure are stored only as one-way hashes or encrypted with AWS KMS, never in plaintext.

• Source control: All code is managed in GitHub with MFA-enforced access
• Code review: Changes are reviewed before merge
• Automated testing: Pre-commit validation, qualification testing, and regression suites run before deployment
• Staged deployment: Changes go through testing and qualification phases before reaching production
• Infrastructure as code: Infrastructure changes are managed through Terraform, providing version-controlled, reviewable modifications

Intrusion detection and prevention is handled through multiple layers:

• AWS Shield Standard: Baseline protection against common network and transport layer DDoS attacks, automatic on the AWS services we use
• AWS security controls: Network-level protections including VPC flow logging capabilities and security group enforcement
• Application monitoring: Grafana Cloud provides real-time monitoring and alerting on anomalous system behavior

We use AWS WAF and AWS Shield rather than a standalone IDS/IPS appliance. Our approach relies on AWS network controls, application-level monitoring, and security group enforcement.

• Principle of least privilege: Production access is limited to essential personnel only
• MFA everywhere: Required for AWS Console, GitHub, and all internal administrative systems
• No shared credentials: Every individual has their own account with MFA
• Customer access controls: Organizations manage their own user access with organization-scoped permissions
• Password reset security: Token-based (UUID), 2-hour expiration, one-time use

• Application monitoring: Grafana Cloud provides real-time dashboards, metrics, and alerting for system health and performance
• Infrastructure logging: AWS provides CloudTrail and VPC flow log capabilities for infrastructure-level audit trails
• Alerting: Automated alerts for anomalous behavior, error rate spikes, and resource utilization thresholds

• Artifact storage (S3): Amazon S3 provides 99.999999999% (11 nines) durability. Versioning is enabled on all buckets.
• Database (DynamoDB): Automated backups with point-in-time recovery, allowing restoration to any second within the retention window.
• Infrastructure as code: All configuration stored in version-controlled Terraform, allowing full environment recreation.

Object versions stay in US-West (N. California); the replicated account table keeps point-in-time recovery in each of its three US regions.

• Triage: Security issues are triaged and responded to within one business day
• Contact: Security incidents can be reported to security@cloudrepo.io
• Communication: Affected customers are notified of incidents that impact their data
• Status page: System availability incidents are communicated via status.cloudrepo.io
• Track record: No known security breaches in our history.

• All code managed in GitHub with MFA-enforced access
• Code review required before merge to the main branch
• Pre-commit validation and automated checks
• Comprehensive test suites in the CI/CD pipeline
• Multi-phase qualification gates (static analysis, unit tests, integration tests, security checks)
• Infrastructure as code via Terraform with review and version control
• Passwords hashed with PBKDF2+BLAKE2b-512 (50,000 iterations, 12-byte salt)
• Application-level input validation on all user inputs
• Dependency monitoring for known vulnerabilities