Skip to main content

Security

Security is a shared engineering responsibility across the Ubujima ecosystem.

This public page describes contributor-facing security principles. It intentionally does not document internal security architecture, production topology, privileged endpoints or operational controls.

Core Principles​

Ubujima projects should follow these principles:

  • Least privilege
  • Secure defaults
  • Defense in depth
  • Clear authorization boundaries
  • Protection of personal and confidential data
  • Responsible dependency management
  • Secure secret handling
  • Review before production changes
  • Responsible vulnerability disclosure

Access Control​

Access should be granted according to role and need.

A contributor working on a public interface should not automatically receive access to private repositories, production environments, user data or internal infrastructure.

Access should be reviewed as responsibilities change.

Secrets​

Never commit secrets to repositories.

Examples include:

  • Passwords
  • API keys
  • Access tokens
  • Private keys
  • Signing secrets
  • Database credentials
  • Production configuration containing sensitive values

If a secret is accidentally exposed, treat it as compromised and follow the relevant incident process rather than simply deleting it from the latest commit.

Authentication and Authorization​

Authentication establishes identity. Authorization determines permitted actions.

Applications and services must enforce authorization for protected operations and must not rely solely on client-side restrictions.

Data Protection​

Projects should collect, process and retain only the information reasonably needed for their purpose.

Security and privacy considerations should include:

  • Data classification
  • Access controls
  • Encryption where appropriate
  • Retention
  • Logging practices
  • User consent where required
  • Safe deletion and lifecycle management

Sensitive data should not be copied into development environments without an approved reason and appropriate protection.

Secure Development​

Contributors should:

  • Validate external input
  • Avoid exposing sensitive error details
  • Use maintained dependencies
  • Review authentication and authorization changes carefully
  • Keep secrets out of source code
  • Test security-relevant behavior
  • Document significant security assumptions

Dependencies​

Third-party packages introduce supply-chain risk.

Before adding a dependency, consider:

  • Is it actively maintained?
  • Is the package necessary?
  • Is its license compatible?
  • Does it introduce known vulnerabilities?
  • Can the required capability be implemented more safely with existing tools?

Dependencies should be updated intentionally and tested.

Logging​

Logs should help diagnose problems without becoming a secondary store of sensitive information.

Avoid unnecessarily logging:

  • Passwords
  • Tokens
  • Private keys
  • Full payment data
  • Sensitive personal information
  • Confidential request payloads

Client and API Security​

Public clients should be treated as untrusted environments.

Secrets must not be embedded in frontend code. APIs must validate requests and enforce authorization on the server side.

Rate limiting, abuse prevention and request validation should be introduced according to risk and product requirements.

Production Changes​

Production changes should be controlled, reviewable and limited to authorized contributors.

Developers should use development, test or staging environments for experimentation.

Vulnerability Reporting​

If you discover a security vulnerability, do not publish exploit details before the issue can be responsibly reviewed and addressed.

Use the project-specific security reporting channel when one is provided. If no channel is documented, contact the relevant project maintainers privately.

Security Documentation Boundaries​

Public documentation should help contributors build securely without exposing information that would unnecessarily increase operational risk.

Detailed incident procedures, privileged infrastructure, production endpoints, access-control implementation and other sensitive security information belong in controlled internal documentation.

Security is strongest when it is built into engineering decisions from the beginning.