This document explains how security vulnerabilities and security-related concerns should be reported in the Bugema Linux project.

Bugema Linux is an open-source project of the Bugema Open Source Community (BOSC) at Bugema University, Uganda.

Security is a fundamental requirement of the project because Bugema Linux is intended to become an operational Linux platform for teaching, learning, research, innovation, and selected institutional computing environments.

Bugema Linux follows these principles:

• Security should be considered throughout the development lifecycle.
• Security issues should be reported responsibly.
• Vulnerabilities should not be unnecessarily exposed before they can be investigated.
• Software dependencies should be monitored.
• Build processes should be reproducible where practical.
• Contributors should avoid committing secrets or credentials.
• Security-sensitive changes should receive appropriate review.
• Releases should be tested before distribution.

Examples of security issues include:

• Remote code execution vulnerabilities
• Privilege escalation
• Authentication bypass
• Unauthorized access
• Malicious package behavior
• Insecure default configurations
• Credential exposure
• Secret or API-key exposure
• Build-system vulnerabilities
• Supply-chain vulnerabilities
• CI/CD security vulnerabilities
• Installer security vulnerabilities
• Vulnerabilities that could compromise Bugema Linux users

If public disclosure could increase the risk to users or infrastructure, do not create a public GitHub issue.

Do not publicly disclose:

• Passwords
• API keys
• Access tokens
• Private certificates
• SSH private keys
• Database credentials
• Confidential institutional information
• Personally identifiable information
• Exploit details that could immediately put users at risk

If any secret is accidentally committed to the repository, notify the project maintainers immediately.

Removing a secret from the latest commit does not necessarily make it safe because it may remain in Git history.

Security vulnerabilities should be reported through GitHub's private security reporting mechanism where available.

Project maintainers should use GitHub's repository security features to receive and manage confidential vulnerability reports.

If private reporting through GitHub is not available for a particular issue, contact an authorized Bugema Linux maintainer privately.

Do not use a public GitHub Issue for a potentially serious vulnerability.

A useful security report should contain, where possible:

• Description of the vulnerability
• Affected component
• Affected version or commit
• Steps required to reproduce the issue
• Expected behavior
• Actual behavior
• Potential impact
• Relevant logs
• Proof-of-concept information where appropriate
• Suggested mitigation, if known

Avoid including unnecessary sensitive information.

Maintainers should acknowledge a security report as soon as reasonably practical.

The initial review should determine:

1. Whether the report relates to Bugema Linux.
2. Whether the issue is reproducible.
3. Which components are affected.
4. The potential impact.
5. Whether immediate mitigation is required.

Security investigations should be handled by authorized maintainers and relevant technical contributors.

The investigation may involve:

• Reproducing the vulnerability
• Reviewing source code
• Examining dependencies
• Reviewing build processes
• Testing affected configurations
• Determining affected versions
• Identifying possible mitigations

Access to sensitive vulnerability information should be limited to people who need it.

Depending on the severity and nature of the issue, remediation may involve:

• Code changes
• Configuration changes
• Package updates
• Dependency updates
• Build-system changes
• Documentation updates
• Release updates
• Temporary feature restrictions
• Removal of affected components

Security fixes should receive appropriate testing before release.

Security vulnerabilities should be disclosed responsibly.

The timing and content of public disclosure should consider:

• Availability of a fix
• Availability of a mitigation
• User exposure
• Severity
• Upstream vulnerabilities
• Dependency disclosure requirements

Where appropriate, Bugema Linux may coordinate disclosure with upstream open-source projects.

Bugema Linux may depend on software developed by other open-source projects.

When a vulnerability originates in an upstream dependency, maintainers should follow the upstream project's security guidance and update process.

Contributors should avoid unnecessarily duplicating sensitive vulnerability details in public project discussions.

The project should periodically review important dependencies.

Where practical, contributors should:

• Keep packages updated.
• Avoid unnecessary dependencies.
• Verify package sources.
• Review dependency licenses.
• Monitor known vulnerabilities.
• Remove obsolete dependencies.

Secrets must not be committed to the repository.

Examples include:

API keys
Passwords
Private keys
Tokens
Cloud credentials
Database credentials
Signing credentials

Use appropriate secret-management mechanisms for development and CI/CD.

If a secret is exposed:

1. Notify the responsible maintainer.
2. Revoke or rotate the secret.
3. Remove the secret from active project files.
4. Assess whether Git history requires remediation.
5. Investigate potential unauthorized use.

Contributors should consider security when developing:

• Installation scripts
• Package configurations
• System services
• Network configurations
• Authentication mechanisms
• Build systems
• CI/CD workflows
• Update mechanisms
• Desktop applications
• Administrative tools

Security-sensitive changes should receive additional review.

Students may use Bugema Linux for cybersecurity learning and research.

Security testing must be performed only on systems for which the student has appropriate authorization.

Students must not use Bugema Linux project infrastructure to conduct unauthorized attacks or penetration tests.

Research activities should follow applicable Bugema University requirements.

As the project matures, security testing may include:

• Dependency scanning
• Static analysis
• Configuration review
• Package verification
• Vulnerability scanning
• Installation testing
• Permission testing
• Network security testing
• Container or virtual-machine testing
• CI/CD security checks

The exact security testing process will evolve with the project.

Important security fixes should be documented through appropriate project mechanisms.

Depending on the circumstances, this may include:

• GitHub security advisories
• Release notes
• Changelog entries
• Updated documentation

As Bugema Linux grows, BOSC may establish a dedicated security team responsible for coordinating:

• Vulnerability reports
• Security testing
• Dependency monitoring
• Security documentation
• Security reviews
• Incident response

Membership and permissions should follow the project's governance and least-privilege principles.

Bugema Linux encourages responsible security research.

Researchers who identify legitimate vulnerabilities are encouraged to report them privately and provide sufficient information to reproduce and address the issue.

Researchers should avoid unnecessary access to data or systems that are not required to demonstrate the vulnerability.

This security policy will evolve as the Bugema Linux architecture, infrastructure, and community mature.

Changes should be reviewed according to the project's governance process.

Bugema Linux Bugema Open Source Community (BOSC) Bugema University, Uganda

Secure by design. Open by collaboration.