Secure defaults

Workshop provides secure defaults to make the safe path the easy path, allowing you to get up and running quickly without having to become experts on GitLab configuration and security.

In most cases we allow customers to override these defaults. These overrides may have consequences when it comes to shared responsibilities for your ATO.

Noted secure defaults

Projects

Projects created using your Workshop control repository have settings enforced by infrastructure as code. This allows for easily configured and continuously enforced and auditable security settings on projects.

• Protected branches using push rules (push_rules) - Protecting your default branch, (main by default), is a basic part of proper secure development. Code should never enter protected branches without proper review. Workshop supports additional tuning but defaults to the following rules applied to your protected branches:
  • Requiring merge requests - Merge requests, (a.k.a. "pull requests" in GitHub parlance), are the basis for the light change control process central to most development teams. In most cases automated checks (CI) must pass and an authorized peer must review and approve the change prior to merging into a protected branch.
  • Requiring pushes to be from members of the repository (member_check: true) - The user must be part of a group with Developer or higher level access to push to the repository.
  • Requiring commits to be from verified email addresses of members of the repository (commit_committer_check: true) - This ensures that all email addresses used for commits are verified. You can combine this with the author_email_regex setting to restrict which email addresses are allowed to commit.
  • Requiring signed commits (reject_unsigned_commits: true) - All commits must be cryptographically signed with a SSH key, GPG key, or X.509 certificate to provide traceability back to the committer.
• Secret detection (prevent_secrets: true) - This scans code to prevent accidentally leaking passwords, API keys, and other common types of technical secrets. It is all too easy to accidentally include a file with a secret in a commit. In the best case it is toilsome to rotate the secret and cleanup. In the worst case your system may be compromised due to a leaked secret.
  • Secret detection rules are not perfect and sometimes you may want to push a benign sample secret in your code. In this case you can use secret detection exclusions to resolve a false positive.

Enforcement

Settings are enforced by infrastructure as code (IaC) for managed resources.

More

The full set of project level settings is documented in Workshop / Project Templates / Workshop Customer Config Template.