Security hardening

Why this matters

Most repository security is a short list of settings, and most breaches come from the items nobody turned on. You may not own the settings, but noticing that they are missing is a genuine contribution, and the list is short enough to check in ten minutes.

The list, in order of value

The order is deliberate. Two-factor authentication and a protected default branch prevent more real incidents than everything below them combined.

Credential hygiene

The habits, from Section 8 and lesson 9.12:

• The least powerful credential that works: a read-only deploy key beats a personal token for a build server.
• An expiry on everything, so a forgotten credential expires rather than lingering.
• A periodic review of your own tokens and keys, and of the project's.
• Never a personal token in automation, because it carries all your access and dies with your account.
• Rotate on any doubt. Revoking is instant; the alternative is hoping.

Secret scanning

Both platforms scan pushes and repository content for patterns that look like credentials, and can alert or block. Two things worth understanding:

• Detection is not prevention. By the time a scanner alerts, the secret has been pushed and must be treated as leaked: rotate it first, then clean history if you must (lesson 8.7).
• Push protection, where available, refuses the push instead, which is the version that actually prevents the incident. It is worth asking for.

A local pre-commit hook adds a third layer, one second after the mistake (lesson 18.4), with the usual caveat that it can be skipped.

Dependency alerts

Both platforms read your dependency files and warn about known vulnerabilities, and both can open a merge or pull request that updates the version.

For a non-developer the useful contribution is not the fix, it is the process: making sure someone owns the alerts, that the automated update requests are reviewed rather than accumulating, and that the changelog entry says what changed. An ignored alert queue is worse than no alerts, because it looks like coverage.

Audit logs

An audit log records who changed what, and it is the control that makes the others durable: a protected branch that someone quietly unprotected is not a control.

Access is usually limited to owners, and retention varies by plan. The practical version for everyone else: if a rule you rely on disappears, ask, because the log will say.

What you can do without owning the settings

A short and genuinely useful list:

1. Read the settings you can see. Rulesets are visible to anyone with read access on GitHub; protected branches are visible on GitLab.
2. Ask about the gaps, once, in writing: two-factor enforcement, a protected default branch, required review, secret scanning.
3. Fix your own half: token expiry, least privilege, two-factor, signed commits (lesson 18.3).
4. Add a pre-commit secret check for yourself, and propose it for the project.
5. Watch the alert queues and raise it when they grow.

Written once, politely, in an issue, that list is a contribution most teams welcome and few people make.

How to do it

$ git config --global commit.gpgsign true
$ git config --global gpg.format ssh
$ cat .gitignore

Common mistakes

• Treating detection as prevention. A secret-scanning alert means it already leaked; rotate first.
• Cleaning history and not rotating the credential. The clean-up is optional; the rotation is not.
• Tokens with no expiry.
• A personal token in CI.
• Alert queues nobody owns, which look like coverage and are not.
• Relying on a hook as a control (lesson 18.4).
• Assuming someone senior has checked. Often nobody has, which is why the ten-minute review is worth doing.