Security & Compliance

Security & compliance

How we approach security, data protection, and intellectual property when partnering with institutional clients.

Our posture

Yudame is a small team, and the security approach reflects that. We keep the surface area narrow and reach for well-understood defaults before anything bespoke. Lose a client's trust once and you don't get it back, so we don't gamble with it. Everything on this page is something we already do, not a roadmap.

Secure software development lifecycle

We follow conservative, well-understood engineering practices on every engagement:

Code review on every change. No code reaches a main branch without a pull-request review by a second engineer.
Dependency review. We vet third-party packages when they come in and update them on purpose, not whenever a bot opens a version-bump PR.
Secrets stay out of source control. Credentials, tokens, and API keys live in environment files or platform secret stores; they are never committed to repositories.
Least-privilege access. When we work in a client's systems, we request only the access we need and hand it back at engagement end.
Threat modeling at the design stage for engagements that touch sensitive data, financial transactions, or regulated environments. We find the risks at the whiteboard, while they're still cheap to fix.

Mobile and web application security

We reference the OWASP MASVS (Mobile Application Security Verification Standard) for mobile work and the OWASP ASVS (Application Security Verification Standard) for web work as design and review checklists. They give us a shared vocabulary for talking about authentication, session handling, data storage, transport security, and platform interaction.

We do not claim formal certification against either standard. We use them the way most working engineering teams do: as a structured prompt for the questions a thoughtful reviewer would ask.

Data protection

Our defaults for handling client data:

Encrypted in transit. All client traffic moves over TLS. We do not stand up plaintext endpoints, even for internal tooling.
Production stays out of development. Production credentials and personally identifiable information are not copied into development environments without explicit client authorization. When sample data is needed, we prefer synthetic or anonymized fixtures.
Data minimization. We collect and retain only what an engagement requires, and we delete it when the engagement ends or when the client asks us to.
AI tooling boundaries. When we use third-party AI services in a client engagement, we scope what data is sent to them, prefer providers that do not retain prompts for training by default, and flag the choice to the client up front.

Intellectual property and knowledge transfer

Source code, documentation, and the operational knowledge needed to run what we build belong to the client. At engagement end we hand over the repository, deployment configuration, and the runbook a successor team needs to keep things working. There are no hidden runtime dependencies on Yudame infrastructure.