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. Our security approach reflects that: we keep the surface area narrow, prefer well-understood defaults over bespoke tooling, and treat client trust as the most expensive thing we own. Anything we publish here is something we already practice today — not an aspirational 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. Third-party packages are reviewed when introduced and updated deliberately rather than on autopilot.
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 involving sensitive data, financial transactions, or regulated environments — surfacing risks before code is written rather than after.

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.