Security Guides

Who should read which part of an SBOM: engineer, buyer or auditor?

Nobody needs to read every line of an SBOM. A role by role guide to which fields an engineer, procurement lead, security manager and auditor should look at.

Who should own the third-party SDK and API inventory?

Product teams should own their own rows and security should own the system and the checks. Here is a simple split that keeps the inventory current.

Who should own the security inbox at a small software vendor?

Use a team address with a named weekly owner and a backup. How a small software vendor keeps security reports from getting lost in a shared mailbox.

Who should own a client's hosting, domain and code accounts?

The client should own the domain, hosting and code accounts, with the agency added as a named user. That keeps the site portable and access easy to remove.

Who should join a dependency compromise tabletop exercise?

Which roles to invite to a dependency compromise tabletop, what each one decides, and which absent seat causes the most trouble in a real incident.

Who should hold the OTA signing key at a ten person startup?

Nobody should hold the OTA signing key on a laptop. Here is how a small hardware team can split signing roles so one stolen account cannot ship malware.

Who in your company should be able to see live API keys?

As few people as possible. Define who may create, read and update live keys, route them through a vault, audit use, and keep staff on sandbox keys.

Who should have publish access in Google Tag Manager?

Give most people Edit or Approve and keep Publish to a few named owners. Here is what each Tag Manager permission level allows and how to assign them.

Who should have access to vulnerability reports and scan results?

A vulnerability list is a map for attackers. Limit access by role, log who views it, and share summaries more widely than raw findings with others.

Who should have access to a staging environment?

Give staging access to the people and systems that need it, by role, with single sign on, no shared accounts and an expiry. A practical model.

Who should get SBOM drift alerts, and how often?

Send SBOM change alerts to the team that owns the service, keep them rare, and group the rest into a digest. A routing table and a short rollout plan.

Who should be allowed to edit your organization workflow templates?

Your .github template repository sets the starting point for new CI files. Limit who can change it, require review, and keep an audit trail of every edit.