Answer by describing five concrete controls: who can change the pipeline, what credentials it holds, how third party steps are referenced, how builds are made repeatable, and how changes are reviewed and logged. Give one setting or file as evidence for each, and state what you have not done yet.
What the reviewer wants to see
This question tests whether one stolen account or one poisoned step can push code to customers. They do not expect a perfect setup from a small company. They expect you to know where the risks are and to have handled the obvious ones.
A structure for your answer
| Area | A truthful sentence | Evidence |
|---|---|---|
| Access to change | Changes to pipeline files need review, and direct pushes to the main branch are blocked | Branch protection export |
| Credentials | The pipeline uses scoped credentials, separate per environment, and the default token is read only | Workflow permissions block, secrets list with scopes, no values |
| Third party steps | External actions and plugins are pinned to fixed references and reviewed on update | Sample workflow |
| Repeatable builds | Dependencies install from lockfiles and builds fail on mismatch | CI log or config |
| Logging | Pipeline runs and deployment approvals are retained | Run history, approval log |
Adapt each sentence to what you really do. If you only do three of five, answer three and say the others are planned.
A model paragraph
"Changes to our build pipelines are made through pull requests that require review, and direct pushes to the main branch are blocked. Pipeline credentials are scoped per environment, and the default token is read only, with extra permissions granted per job. External build steps are pinned to fixed versions. Dependencies install from lockfiles. Production deployments need a named approver, and run history is retained. We have not yet implemented signed build provenance and plan to evaluate it next year."
Notice the last sentence. A named gap, with a plan, reads as credible.
Reference points reviewers recognise
NIST's Secure Software Development Framework describes a core set of high level secure development practices for producers to integrate into their own lifecycle. You can say your controls align to specific practices there, naming which ones, but avoid saying you are compliant with it.
What to avoid
- "Our pipeline is fully secure."
- Listing tools instead of controls.
- Claiming signed builds or provenance that you do not produce.
- Leaving out that production deploys can be triggered by a single person, if that is true.
Make it checkable
Attach exports with dates. A reviewer who sees real settings stops asking follow up questions. If you can add one more control cheaply, pin your external actions to full commit SHAs, as GitHub's hardening guide explains it mitigates the risk of a backdoor in the action repository.
For the settings themselves, see how to lock down GitHub Actions for a small team.
Safeguard policies and gates can add a check that blocks a pull request on a failing result, and the free scan at https://gold.safeguard.sh/scan is a quick way to produce a first dated report.
Quick check
Do we need signed builds to answer this?
No. Describe what you do today. If you do not sign builds, say so and note any plan.
Is it fine to name our CI vendor?
Yes, naming your own tooling is normal. Focus the answer on controls rather than product names.
How long should the answer be?
A short paragraph plus attachments. Reviewers prefer specifics over length.
Sources
- GitHub Docs, Security hardening for GitHub Actions
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 19 October 2026.
