Reporting a vulnerability? See the Vulnerability Reporting section

We understand that our users place a high level of trust in Blackspace. The security of Blackspace is a top priority. That's why we apply widely accepted best practices when it comes to security. This document will describe these practices and aims to be as transparent as possible on our security efforts.

• # Security Policy
• Project Structure
  • Transparency
    • Open Source
    • Workflow
  • Version Control
    • Git
    • Signed Commits
    • Protected Branches
• Personnel
  • Education
  • Policies
  • Two-factor Authentication
• Development
  • Design & Architecture
    • Golang
    • Unsafe Code
    • User Privileges
  • Dependencies
  • Change Control
    • Pull Requests
    • Reviews & Approvals
    • Merge Policies
    • Automated Checks
      • Vulnerability Scans
      • Fuzz Testing
• Building & Releasing
  • Network Security
  • Runtime Isolation
  • Asset Audit Logging
  • Asset Signatures & Checksums
• Vulnerability Reporting

Project structure plays an important role in security. It creates guardrails that prevent common security issues. This section will outline our deliberate structural decisions that impact security.

We believe transparency is a strong deterrent of nefarious behavior that could otherwise undermine security.

Blackspace's dependencies are open-source. All code and changes are publicly available at our Github repo.

All of Blackspace's workflow is transparent. Pull requests, issues, chats, and our roadmap are all publicly available.

Version control ensures that all code changes are audited and authentic.

Blackspace leverages the Git version-control system. This ensures all changes are audited and traceable.

Because of Blackspace's merge style, commits to release branches are signed by Github itself during the squash and merge process. Commits to development branches are encouraged to be signed but not required since changes must go through a review process.

Blackspace cuts releases from the master and v* branches only. These branches are protected. The exact requirements are:

• Cannot be deleted.
• Force pushes are not allowed.
• A linear history is required.
• Signed commits are required.
• Administrators are included in these checks.

Blackspace team members are required to review this security document as well as the contributing and reviewing documents.

Blackspace maintains this security policy. Changes are communicated to all Blackspace team members.

All Blackspace team members are required to enable two-factor authentication for their Github accounts.

The base of Blackspace's security lies in our choice of underlying technology and decisions around design and architecture.

The [Golang programming language][urls.go] is not memory and thread-safe; it will not catch many common sources of concurency vulnerabilities at compile time. Hence, it is the responsibility of the developer to properly account for any potential race conditions.

Blackspace does not allow the use of unsafe code except in circumstances where it is required, such as dealing with CFFI.

Blackspace is always designed to run under non-root privileges, and our documentation always defaults to non-root use.

Blackspace aims to reduce the number of dependencies it relies on. If a dependency is added it goes through a comprehensive review process that is detailed in the Reviewing guide.

As noted above Blackspace uses the Git version control system on Github.

All changes to Blackspace must go through a pull request review process.

All pull requests must be reviewed by at least one Blackspace team member. The review process takes into account many factors, all of which are detailed in our Reviewing guide. In exceptional circumstances, this approval can be retroactive.

Blackspace requires pull requests to pass all automated checks. Once passed, the pull request must be squashed and merged. This creates a clean linear history with a Blackspace team member's co-sign.

When possible, we'll create automated checks to enforce security policies.

Blackspace will implement an automated cargo deny check. This is a security checker for golang source code.

Blackspace will implement automated fuzz testing to probe our code for other sources of potential vulnerabilities.

Blackspace takes care to secure the build and release process to prevent unintended modifications.

All network traffic is secured via TLS and SSH. This includes checking out Blackspace's code from the relevant protected branch, Docker image retrieval, and publishment of Blackspace's release artifacts.

All builds run in an isolated sandbox that is destroyed after each use.

Changes to Blackspace's assets will be logged through Digital Ocean's blob storage audit logging feature.

All assets are signed with checksums allowing users to verify asset authenticity upon download. This verifies that assets have not been modified at rest.

We deeply appreciate any effort to discover and disclose security vulnerabilities responsibly.

If you would like to report a vulnerability or have any security concerns with Blackspace, please e-mail yoanyombapro@gmail.com.

For non-critical matters, we prefer users open an issue. For us to best investigate your request, please include any of the following when reporting:

• Proof of concept
• Any tools, including versions used
• Any relevant output

We take all disclosures very seriously and will do our best to rapidly respond and verify the vulnerability before taking the necessary steps to fix it. After our initial reply to your disclosure, which should be directly after receiving it, we will periodically update you with the status of the fix.