Most security reviews fail before anyone opens a scanner. The team asks broad questions, gets broad answers, and walks away with a false sense of control.
Security questions examples are useful only when they change decisions. If the question does not expose who owns a risk, what evidence proves control, or what breaks during a malicious pull request, it becomes meeting theater.
Teams think the problem is having better questionnaires. The real problem is designing review questions around the actual software delivery workflow: source, CI, dependencies, artifacts, secrets, deployment, and response.
That changes the conversation. A useful security question is not a trivia prompt. It is a small test of architecture, trust boundaries, and operational ownership.
Table of contents
- Security questions examples are workflow tests
- Start with the asset and trust boundary
- Security questions examples for CI/CD pipelines
- Security questions examples for dependencies
- Ask about secrets like an attacker would
- Release and artifact questions that matter
- What works and what fails in reviews
- Implementation workflow for a better question bank
- Common failure modes
- Where vu1nz.com fits
- Closing checklist
Security questions examples are workflow tests
Security questions examples should not be treated as a generic list copied into a ticket template. In CI/CD and supply-chain security, the same question can be useful or useless depending on where it sits in the workflow.
Ask whether dependencies are reviewed, and most teams will say yes. Ask what happens when a pull request adds a new npm package with an install script, a brand-new maintainer, and no lockfile diff review, and the answer gets more interesting.
The mistake teams make is asking questions that measure policy awareness instead of execution reality.
The question has to map to a control
A practical question maps to a specific control, signal, or decision. If nobody can point to a GitHub setting, workflow file, package diff, log event, admission rule, or release gate, the question is too abstract.
Bad question:
- Do we secure CI/CD?
Better questions:
- Which workflows can run on pull requests from forks?
- Which jobs receive write permissions to repository contents?
- Can untrusted code influence a build step before secrets are available?
- Which package additions require human approval?
- Are release artifacts built from reviewed commits only?
Practical rule: if the answer cannot be verified from configuration, logs, code, or a documented owner, rewrite the question.
This is why security questionnaires often disappoint engineering teams. They ask whether a process exists, but attackers exploit the gap between process and execution.
Ask for evidence, not confidence
Security reviews become useful when every answer includes evidence. Evidence can be a workflow file, a policy-as-code rule, an artifact signature, a secret inventory, an alert, or a runbook.
A strong review question has three parts:
- What condition are we testing?
- What evidence proves it?
- Who changes the system if the evidence is bad?
For example: Which GitHub Actions workflows grant id-token: write, and what prevents an untrusted pull request from reaching those jobs?
That question points to configuration, threat model, and ownership. It is not a vague discussion about whether OIDC is secure.
Related reading from our network: SOC teams face a similar ownership problem during live incidents, and the operating model in Incident Commander: The SOC Operating Role That Keeps Response From Collapsing is useful when CI/CD security incidents need a clear decision-maker.
Start with the asset and trust boundary
You cannot ask good security questions until the team agrees on what matters. In software supply chains, the asset is rarely just application source code. It is also the build identity, release pipeline, package manager state, signing key, deployment token, and customer-facing artifact.
What are we actually protecting
Start each review with asset questions:
- What repositories can produce production artifacts?
- What workflows can publish packages, containers, or releases?
- What service accounts can deploy to production?
- What package registries does the application trust?
- What secrets are required for a full release?
- Which branch, tag, or environment is the source of truth?
This seems basic, but many teams cannot answer it cleanly. Monorepos, shared workflows, reusable actions, and multi-cloud deployment paths blur ownership.
A useful way to think about it is to list the systems that can change what customers run. Anything in that path belongs in scope.
Where does untrusted code enter
The practical question is not whether your repository is private. The practical question is where untrusted input can influence execution.
Common entry points include:
- Pull requests from forks
- New dependencies and transitive dependencies
- Build scripts from package managers
- Third-party GitHub Actions
- Generated code
- Container base images
- Test fixtures and sample files
- Developer machines pushing signed commits
If a workflow checks out attacker-controlled code and then exposes credentials, the trust boundary has already failed. If a dependency install runs lifecycle scripts before review, the package manager is part of the execution boundary.
Practical rule: draw the trust boundary around execution, not around the repository name.
A private repo can execute hostile dependency code. A public repo can have a safe release path. The difference is architecture.
Security questions examples for CI/CD pipelines
Security questions examples for CI/CD should focus on execution paths, permissions, and state transitions. CI is not just automation. It is a privileged compute environment that reads source, runs code, accesses secrets, produces artifacts, and sometimes deploys.
What breaks in practice is that teams secure application code but leave the delivery system under-reviewed.
Questions for workflow permissions
Use questions that force the team to inspect permissions, not just describe intent:
- Which workflows use permissions: write-all or broad default permissions?
- Which jobs need contents: write, packages: write, id-token: write, or pull-requests: write?
- Are permissions set at the workflow level, job level, or inherited by default?
- Can a build job write to the repository, or only a release job?
- Are reusable workflows pinned to immutable references?
- Can a third-party action access tokens or secrets in the same job?
A better review does not say minimize permissions and move on. It asks why each permission exists.
Example permission posture:
| Area | Weak question | Better security question | Evidence |
|---|---|---|---|
| GitHub token | Is the token secure? | Which jobs receive write permissions and why? | workflow YAML |
| OIDC | Do we use OIDC? | Which jobs can request cloud credentials? | id-token usage and cloud trust policy |
| Actions | Are actions approved? | Are third-party actions pinned to SHAs? | workflow references |
| Releases | Are releases protected? | Can non-release jobs publish artifacts? | job permissions and environment rules |
Teams using GitHub Actions can automate part of this review with the vu1nz GitHub Action for CI/CD and package security scanning, especially where workflow permissions and risky package additions need to be checked before merge.
Questions for pull request execution
Pull requests are where many CI/CD trust failures start. The review should separate code review from code execution.
Ask:
- Do pull_request and pull_request_target workflows behave differently?
- Can attacker-controlled code run in a context with repository write tokens?
- Are secrets available to workflows triggered by external contributors?
- Does any job check out pull request code before using privileged credentials?
- Are labels, comments, or issue events used to trigger privileged behavior?
- Can a contributor modify workflow files and cause them to run in the same pull request?
The dangerous pattern is mixing untrusted code with trusted credentials in one job. The safer pattern is to test untrusted code in a constrained context, then require a separate trusted workflow for privileged actions.
Practical rule: never treat a pull request event as safe just because it came through the normal review process.
Security questions examples for dependencies
Dependency security questions are often too CVE-centered. Known vulnerabilities matter, but supply-chain attacks frequently happen before a CVE exists. A malicious maintainer release, typosquat, dependency confusion issue, or compromised package token will not wait for your advisory feed.
Security questions examples for dependencies should test admission, execution, and monitoring.
Questions for new packages
New package additions deserve more scrutiny than routine patch updates. Ask:
- Who approved the new direct dependency?
- Is the package name similar to an internal or popular package?
- Does the package run install, postinstall, prepare, or build scripts?
- Is the maintainer history consistent with the package importance?
- Is the package pinned through a lockfile?
- Does the package introduce native code, network calls, or binary downloads?
- Is there a smaller existing dependency that already covers the need?
The mistake teams make is treating dependency additions as normal code diffs. They are trust decisions. A small package can execute during install, modify build outputs, or steal environment variables.
For adjacent detail, our prior writeup on what Dependabot misses in npm supply-chain attacks is relevant because the hard cases are often not known-CVE cases.
Questions for dependency updates
Updates are not automatically safe. A patch release can be malicious. A transitive dependency can change the effective codebase without a developer touching application logic.
Ask:
- Does the lockfile diff match the declared dependency change?
- Did a transitive dependency introduce lifecycle scripts?
- Is the update from a package with recent ownership transfer?
- Are package registry URLs pinned and expected?
- Could dependency confusion resolve an internal name from a public registry?
- Are private packages scoped and authenticated correctly?
A useful dependency review separates four cases:
| Change type | Risk pattern | Review expectation |
|---|---|---|
| New direct dependency | New trust relationship | Human approval plus automated checks |
| Major update | API and behavior shift | Maintainer and changelog review |
| Patch update | False sense of safety | Lockfile and script inspection |
| Transitive update | Hidden execution change | Automated diff and anomaly detection |
Dependency review is not about blocking every update. It is about knowing when the trust graph changed.
Ask about secrets like an attacker would
Secrets reviews often stop at whether secret scanning is enabled. That is not enough. Attackers care about where secrets are exposed, when they are available, what they can access, and how long they survive.
Questions for secret exposure paths
Good questions include:
- Which jobs receive production secrets?
- Are secrets scoped by environment or available repository-wide?
- Can secrets be printed through debug logs, test failures, or command echoing?
- Are secrets passed to third-party actions?
- Are secrets available during dependency installation?
- Are secrets stored in build artifacts, caches, or test snapshots?
- Are cloud credentials short-lived or static?
What breaks in practice is accidental propagation. A secret starts as a deployment credential, then gets copied into a reusable workflow, then becomes available to a broad set of repositories.
Practical rule: secrets should appear as late as possible, in the smallest job possible, for the shortest time possible.
Questions for token blast radius
Every token should have a blast radius review. Ask:
- If this token leaks, what can an attacker change?
- Can it publish a package?
- Can it push to protected branches?
- Can it mint cloud credentials?
- Can it read other repositories?
- Can it access customer data?
- How quickly can it be revoked?
- What logs prove it was used?
Teams often rotate secrets without reducing privileges. Rotation helps after exposure, but it does not fix overbroad authority.
Related reading from our network: identity, session boundaries, and logging show up in other technical domains too; the architecture discussion in ID Streaming in 2026 is a useful comparison for thinking about state and trust outside CI/CD.
Release and artifact questions that matter
A secure pipeline is not complete when tests pass. The release path determines what customers run. If a build can be tampered with after review, the earlier controls only reduce part of the risk.
Questions for provenance
Provenance questions connect source code to build output:
- Which commit produced this artifact?
- Was the artifact built by CI or by a developer workstation?
- Is the build reproducible enough to validate?
- Are artifact hashes recorded?
- Are containers, packages, and binaries signed?
- Can the signature be verified by deployment tooling?
- Are release notes tied to the exact artifact digest?
The practical question is whether you can explain, after an incident, how a production artifact was created. If the answer depends on memory or Slack history, the process is brittle.
Questions for deployment gates
Deployment questions should test who can move code into production and under what conditions:
- Which environments require approval?
- Are approvals performed by people outside the author path?
- Can CI bypass environment protection rules?
- Can a tag trigger production deployment without review?
- Are deployment credentials bound to specific branches or workflows?
- Is rollback also protected, or can it deploy arbitrary old artifacts?
Deployment gates should be boring. Boring means predictable, logged, and hard to improvise around. The risk is usually not that nobody thought about production. The risk is that emergency paths become permanent backdoors.
What works and what fails in reviews
Security reviews become useful when they change engineering behavior without becoming a tax on every pull request. The goal is not to ask more questions. The goal is to ask sharper questions at the right point.
What works
What works:
- Questions tied to a specific pipeline stage
- Evidence required for every answer
- Automated checks for repeatable conditions
- Human review for trust decisions
- Risk scoring based on execution and privilege
- Clear ownership for remediation
- Short feedback loops in pull requests
A strong review question looks like this:
- Condition: A new package was added.
- Risk: The package may execute code during install.
- Evidence: Lockfile diff, package metadata, script fields, registry source.
- Owner: Application team approves need; security reviews anomaly.
- Decision: allow, block, or require deeper review.
That changes the conversation from Are dependencies secure? to Did this pull request create a new execution path?
What fails
What fails:
- Static questionnaires copied across all systems
- Yes/no answers without evidence
- Reviews that happen only before audits
- Scanner output dumped into developer tickets without context
- Security approval that substitutes for engineering ownership
- Ignoring CI permissions because application code passed review
- Treating private repositories as trusted execution zones
The scanner-only review is especially tempting. Tools are necessary, but tools do not understand every business decision. A scanner can flag that a package is new. A human still decides whether the package should exist.
| Review style | What it catches | What it misses | Better use |
|---|---|---|---|
| Generic questionnaire | Policy gaps | Execution-specific risk | Vendor or audit baseline |
| Manual architecture review | Design flaws | Repetitive drift | High-risk systems |
| Scanner-only review | Known patterns | Context and ownership | Pull request guardrails |
| Workflow-based review | Control failures | Requires upkeep | CI/CD and supply-chain risk |
Implementation workflow for a better question bank
A question bank should be maintained like security code. It needs versioning, owners, test cases, and retirement. Otherwise it becomes stale documentation.
Build the first version
Use this sequence:
- Map the delivery path from pull request to production.
- List every system that can execute code in that path.
- List every identity that can write, publish, deploy, or mint credentials.
- Convert each trust boundary into review questions.
- Attach evidence requirements to each question.
- Decide which questions can be automated.
- Put the remaining human questions into pull request or release review.
- Review one real incident or near miss and adjust the questions.
For example, if a workflow publishes a package, the question is not simply whether publishing is protected. Ask which workflow publishes, which token it uses, which branch can trigger it, who approves it, and what artifact digest gets published.
Keep it alive
Question banks rot when the delivery system changes. Add maintenance rules:
- Review questions when adding a new package ecosystem.
- Review questions when adding a new CI provider or reusable workflow.
- Review questions when changing release automation.
- Review questions after every supply-chain incident or blocked attack.
- Delete questions that no longer change decisions.
Practical rule: a stale security question is worse than no question because it teaches the team to ignore the review.
Related reading from our network: local coordination has the same operational issue of routing, ownership, and follow-up, which is why the operating model in Local Community Network Consultant is a useful adjacent reference for process design.
Common failure modes
The same failure modes show up across mature teams and small teams. The tooling changes. The broken assumptions are familiar.
The checkbox review
The checkbox review asks whether controls exist, not whether they work in the dangerous path.
Example:
- Secret scanning is enabled.
- Branch protection is enabled.
- Dependency alerts are enabled.
- CI runs tests.
Those are good baselines, but they do not answer whether a malicious dependency can run during install with access to a registry token. They do not answer whether pull_request_target checks out attacker code. They do not answer whether a release job can be triggered by an unreviewed tag.
The fix is to add scenario questions:
- What happens if a contributor modifies a workflow file?
- What happens if a new package includes a postinstall script?
- What happens if a maintainer token is compromised?
- What happens if an attacker pushes a tag?
Scenario questions expose control gaps faster than abstract compliance language.
The scanner-only review
The scanner-only review assumes automation can replace judgment. It cannot. Automation is strong at repeatable detection. It is weak at business justification and ownership.
A scanner can tell you that a workflow grants broad permissions. It cannot always know whether the permission is temporary, accidental, or required for a release design. A scanner can tell you that a package is new. It cannot know whether the team intentionally accepted the maintainer risk.
The right model is scanner plus question:
- Scanner finds risky condition.
- Question asks why it exists.
- Evidence proves whether it is controlled.
- Owner fixes or accepts the risk.
This is how teams reduce noise. Findings without questions become backlog clutter. Questions without detection become meetings. The combination creates workflow pressure.
Where vu1nz.com fits
vu1nz.com is built around a narrow belief: CI/CD and package supply-chain security should be checked where the risk enters, not months later in a spreadsheet. That means pull requests, workflow diffs, package additions, and release paths.
Questions automation can answer
Automation can answer a large set of security questions examples before a human review starts:
- Did this pull request add a new package?
- Did a workflow permission become broader?
- Did a CI job expose privileged credentials too early?
- Did a workflow use a dangerous trigger pattern?
- Did a package ecosystem change in a way that deserves review?
- Did the lockfile change beyond the declared dependency update?
That is the product-fit area. vu1nz is not a replacement for architecture review. It is a way to surface the parts of the review that should not rely on memory. The scanner gives the team concrete conditions to discuss instead of vague concern.
For broader technical research and CI/CD security writeups from the team, the vu1nz blog is where we publish practical findings, vulnerability analysis, and testing guidance.
Questions humans still own
Humans still own the judgment-heavy questions:
- Should this dependency exist at all?
- Is this release path appropriate for the business impact?
- Should this repository be allowed to publish production artifacts?
- Is this emergency bypass justified, temporary, and logged?
- Who accepts the residual risk?
This boundary matters. If every question becomes automated, teams miss context. If every question stays manual, teams drown in repetitive review. The practical model is to automate detection and preserve human decision-making for trust changes.
Closing checklist
Good security questions examples create a review system that engineers can actually use. They turn vague security concern into pipeline-specific decisions.
Use these questions in the next review
For your next CI/CD or supply-chain review, start with this compact checklist:
- What systems can change what customers run?
- Where does untrusted code execute?
- Which jobs have write permissions or deployment credentials?
- Which dependencies were newly trusted?
- Which secrets are exposed before review is complete?
- Which artifacts can be traced to reviewed source?
- Which release paths bypass normal controls?
- Which answers have evidence?
- Which risks have named owners?
If the team cannot answer these, do not add another generic questionnaire. Fix the workflow visibility first.
Make security questions examples operational
The closing point is simple: security questions examples are not a document type. They are an operating mechanism. They should sit next to the systems they test, fire when the workflow changes, and produce decisions that engineers can act on.
The mistake teams make is trying to make questions comprehensive. Comprehensive usually means nobody uses them. Make them specific, evidenced, and tied to the delivery path.
When security questions examples are built this way, they stop being audit filler and start becoming a practical defense layer for CI/CD and software supply chains.
Try vu1nz.com
vu1nz.com is for security engineers and DevSecOps teams who need to defend CI/CD pipelines and software supply chains from modern attacks. Try vu1nz.com.
Catch the next supply-chain attack on the PR that adds it.
14-day free trial · no card required