A security question example is usually treated like checklist filler. Someone asks whether secrets are encrypted, whether MFA is enabled, or whether dependencies are scanned. The answers go into a ticket. The ticket gets closed. The pipeline keeps shipping.
Teams think the problem is writing better questions. The real problem is designing a review workflow where the answer changes what happens next.
That changes the conversation. In CI/CD and software supply-chain security, a useful security question example is not a trivia prompt. It is a control point. It identifies ownership, evidence, risk, automation, and a merge decision.
The practical question is simple: can your security questions stop a dangerous workflow, dependency, credential path, or release process before it reaches production?
Table of contents
- Why a security question example is an architecture problem
- What a good security question example must prove
- Security question example patterns for CI/CD pipelines
- Security question example patterns for dependencies
- Turn questions into a review workflow
- What works and what fails
- Common failure modes in security question programs
- A practical question library for 2026
- Where vu1nz.com fits
Why a security question example is an architecture problem
Questions are routing logic
The mistake teams make is treating a security question example as a documentation artifact. In practice, the question should route a change into one of several paths: allow, warn, require approval, block, or escalate.
For example, ask: does this pull request add a GitHub Actions workflow that can run on untrusted input with write permissions? If the answer is yes, the workflow should not rely on a developer remembering a policy. The review system should require security approval or fail the check.
That is architecture. The question describes a condition. The answer drives routing. The routing changes merge behavior.
The answer needs an owner
A question without an owner is a comment. A question with an owner is an operational control.
In CI/CD, ownership is often split. Platform owns runners. App teams own workflow files. Security owns policy. Release engineering owns deploy gates. A useful question forces the ownership boundary to become explicit.
Ask: who can approve a change that increases token permissions from read to write? If nobody can answer quickly, the security question is exposing a workflow gap, not just a risk.
Practical rule: every security question should identify the person, system, or team responsible for accepting the answer.
Bad questions create false confidence
Bad questions are broad enough to pass and vague enough to be useless. Is this secure? Are dependencies checked? Are secrets protected? These questions produce yes answers because nobody wants to reopen the release plan.
What breaks in practice is not the lack of security intent. It is the lack of precision. A precise question names the asset, the trust boundary, the condition, and the decision.
A better version is: does this workflow expose repository secrets to a job triggered by a forked pull request, pull_request_target, issue comment, or any other untrusted event path?
That question is harder to hand-wave. It also points directly to what needs to be inspected.
What a good security question example must prove
Evidence beats assertion
A useful security question example should not depend on memory. It should be answerable from evidence: workflow YAML, lockfile diffs, package metadata, registry history, commit signatures, artifact provenance, permission settings, logs, or deployment records.
If the answer requires a meeting, the question may still be valuable, but it is not yet operational. Start by separating evidence questions from judgment questions.
Evidence question: did this pull request add a package with a postinstall script?
Judgment question: is that install script acceptable for this service and environment?
Both matter. They should not be collapsed into one checkbox.
Context decides severity
The same answer can mean different things in different systems. A new npm package in a static docs site is not the same as a new npm package in a release workflow that signs production artifacts. A GitHub token with write permission in a sandbox repository is not the same as one in a monorepo with deploy rights.
Security questions need context from the repository, pipeline, environment, and business process. Without context, teams either block too much or allow too much.
Related reading from our network: SOC teams face a similar routing problem when severity, ownership, and signal quality are disconnected, as described in Critical Incident Approach: A Practical SOC Architecture Guide for 2026.
The question must map to an action
Every strong question has an action map:
- If yes, block merge.
- If yes, require platform approval.
- If yes, open a security review issue.
- If no evidence exists, fail closed for protected branches.
- If accepted, record the exception with an expiration date.
The practical question is not whether the question sounds mature. The practical question is whether the answer changes the system state.
Practical rule: if a security question cannot change a merge gate, approval path, alert, or exception record, it is advisory, not a control.
Security question example patterns for CI/CD pipelines
Workflow permission questions
CI/CD workflow permissions are one of the highest-value review targets because small YAML changes can create large blast radius.
Good questions include:
- Does this workflow request contents: write, packages: write, id-token: write, or actions: write?
- Is the permission granted globally instead of scoped to a single job?
- Can an untrusted contributor influence commands that run with these permissions?
- Does this job mint cloud credentials through OIDC?
A useful way to think about it is permission plus trigger plus input. Permission alone is not enough. Trigger alone is not enough. The failure mode appears when privileged jobs consume attacker-controlled input.
Trigger and pull request questions
The trigger is the trust boundary. Many CI/CD incidents start when teams treat all events as equivalent.
Ask:
- Does this workflow use pull_request_target?
- Does it check out code from the pull request before running privileged steps?
- Does it execute scripts, tests, or package commands from the contributor branch?
- Does it respond to issue comments, labels, or slash commands?
The question should force reviewers to distinguish trusted repository code from untrusted proposed code. That distinction is often where supply-chain attacks become practical.
For teams hardening GitHub workflows, the vu1nz GitHub Action is designed to scan workflow changes for CI/CD vulnerabilities and newly added packages before the PR merges.
Runner and artifact questions
Runners and artifacts are where ephemeral CI becomes persistent risk.
Ask:
- Is this job running on a self-hosted runner?
- Can untrusted code reach that runner?
- Are artifacts uploaded from untrusted jobs and downloaded by trusted jobs?
- Are build outputs signed, verified, or promoted without integrity checks?
Self-hosted runners are not automatically bad. The mistake teams make is using them as if they were disposable hosted runners while giving them network access, cloud credentials, or long-lived caches.
Security question example patterns for dependencies
New package questions
A dependency review should start with the change, not the vulnerability database. Known CVEs matter, but many supply-chain attacks are malicious before they are known.
Good questions include:
- Does this pull request add a new direct dependency?
- Does it add a dependency used in build, test, release, or code generation?
- Does the package run install scripts?
- Does it introduce native code, binary downloads, obfuscated code, or network calls during install?
- Is the package new, renamed, transferred, or recently republished?
This is why a pure CVE mindset misses risk. A malicious package may have no CVE, no advisory, and no obvious version history when it first lands. We covered this gap in detail in What Dependabot Misses, especially for npm attacks that reached users before traditional dependency alerts had anything to say.
Maintainer and registry questions
Package trust is not only code trust. It is account trust, registry trust, publishing process trust, and ecosystem convention.
Ask:
- Did maintainership change recently?
- Is the package name visually similar to a known package?
- Does the registry metadata look inconsistent with the repository?
- Are release artifacts reproducible from source?
- Does the package publish from CI or a local developer machine?
These questions do not prove compromise by themselves. They surface review targets. The goal is to make suspicious changes visible early enough to act.
Install script and build step questions
Install scripts deserve special attention because they run in a developer or CI environment before application code is reviewed deeply. A postinstall script can read environment variables, touch the filesystem, download binaries, or phone home.
Good questions include:
- Does the package execute code during install?
- Does the install path run in CI with secrets present?
- Are package manager flags enforcing script restrictions where appropriate?
- Does the build require network access after dependency resolution?
Practical rule: treat install-time code as pipeline code. It runs inside the build trust boundary even if it lives in a package registry.
Turn questions into a review workflow
Step 1 classify the change
Start by classifying the pull request. Do not ask every question on every change. That creates fatigue and teaches engineers to ignore the process.
A simple classification model:
- Workflow change: GitHub Actions, CI config, runner labels, secrets, OIDC, deploy jobs.
- Dependency change: lockfiles, package manifests, vendored code, build plugins.
- Release change: signing, artifact promotion, deployment configuration.
- Access change: CODEOWNERS, branch protection, permissions, service accounts.
- Application change: normal code paths with no pipeline or dependency impact.
The classification decides which security question examples apply.
Step 2 collect evidence automatically
Automation should collect facts before humans argue about risk. For CI/CD and dependency review, that usually means parsing diffs and extracting structured evidence.
Example evidence fields:
change_type: workflow
workflow_file: .github/workflows/release.yml
new_trigger: pull_request_target
permission_change: contents_write
uses_self_hosted_runner: true
executes_pr_code: unknown
requires_security_review: true
This is not a replacement for engineering judgment. It is a way to make the judgment faster and more consistent.
Related reading from our network: intelligence and OSINT teams run into the same issue when workflows lack schemas and provenance, which is why OSINT Tools in 2026 is useful adjacent reading for teams building evidence pipelines.
Step 3 decide and record the outcome
A working implementation needs a decision record. Otherwise the same argument repeats every month.
Use a short sequence:
- Detect the relevant change type.
- Ask the matching security questions.
- Attach machine evidence to the pull request.
- Route to the correct owner if risk is present.
- Block, approve, or request changes.
- Record accepted risk with scope and expiration.
- Recheck the exception when the system changes.
The output should be visible in the pull request, not buried in a spreadsheet. Developers need to understand why a change is blocked and what specific condition will unblock it.
What works and what fails
What works in production
What works is narrow, evidence-backed, and close to the change. A security question example works best when it is tied to a concrete diff.
Good implementations usually have these properties:
- Questions are scoped by change type.
- Evidence is collected automatically.
- The owner is obvious.
- The decision is enforced near merge time.
- Exceptions expire.
- Questions are reviewed after incidents and near misses.
This keeps the process from becoming ceremonial. It also reduces the political cost of security review because the system explains the trigger.
What fails during implementation
What fails is broad governance copied into engineering workflows. Teams paste a long questionnaire into pull request templates and expect developers to self-assess risk under deadline pressure.
That fails because most risky changes do not announce themselves. A developer adding a package may not know it has an install script. A platform engineer changing permissions may not see how a downstream job consumes pull request input. A release engineer may assume artifact provenance is handled somewhere else.
The fix is not to blame developers. The fix is to move from questionnaire theater to evidence-driven review.
Comparison table
| Approach | What it asks | What it produces | Failure mode |
|---|---|---|---|
| Generic questionnaire | Is this secure? | Vague yes or no | Nobody knows what to inspect |
| PR template checklist | Did you consider dependencies? | Self-attestation | Risky changes pass under deadline pressure |
| Evidence-backed question | Did this PR add a package with install scripts? | Concrete finding | Needs parser maintenance |
| Enforced workflow gate | Did privileged CI become reachable from untrusted input? | Block, approval, or exception | Requires ownership and tuning |
The practical question is where your team wants to spend effort. Manual questionnaires look cheaper, but they push cost into missed reviews, noisy approvals, and incident response.
Common failure modes in security question programs
Questions that cannot block anything
If a question can never block a merge, teams learn it is optional. That does not mean every yes answer must block. It means the program needs at least some conditions that are enforced.
Examples that should usually block protected branches until reviewed:
- Privileged workflow triggered by untrusted pull request context.
- New package with install-time code in a release pipeline.
- Self-hosted runner exposed to untrusted code.
- Artifact promotion without integrity verification.
- OIDC token issuance added to a workflow with unclear audience restrictions.
Security questions become credible when they can stop a dangerous path.
Questions with no telemetry
A question that cannot be measured will drift. Ask whether workflows are least privilege, and you will get opinions. Parse workflow permissions and compare them to job behavior, and you get something reviewable.
Telemetry can be simple:
- Diff scanners.
- Workflow parsers.
- Package manifest analyzers.
- Registry metadata checks.
- Branch protection snapshots.
- Audit log events.
Related reading from our network: teams creating technical content for answer engines face a lighter version of this evidence problem, and Open Dynamics Engine Examples is a useful reminder that examples become useful only when they are specific and citable.
Questions that age badly
Security questions age because platforms change. GitHub Actions adds features. Package managers change defaults. Attackers find new event paths. Your internal release process shifts.
Review the library after:
- A CI/CD incident or near miss.
- A new package ecosystem attack pattern.
- A migration to self-hosted runners.
- A change in artifact signing or deployment.
- A major repository permission change.
A question library is not a policy PDF. It is operational code in human-readable form.
A practical question library for 2026
Pipeline control questions
Use these as starting points, not as a universal checklist.
- Does this workflow run on untrusted events such as forked pull requests, issue comments, or pull_request_target?
- Does any job request write permissions that are broader than needed?
- Can pull request content influence commands in a privileged job?
- Does the workflow use third-party actions pinned by tag instead of commit SHA?
- Does the job access repository, organization, cloud, signing, or package publishing secrets?
- Does the workflow upload artifacts that later trusted jobs consume?
- Does the job run on a self-hosted runner with network access to internal systems?
The answer should be derived from YAML and repository settings wherever possible.
Dependency intake questions
Dependency questions should focus on what changed and how the package behaves inside your pipeline.
- Is this a new direct dependency or a transitive dependency introduced by a direct change?
- Is the package used in runtime, build, test, release, linting, or code generation?
- Does it execute install scripts or download binaries?
- Does it have recent ownership, repository, or publishing changes?
- Is the package name similar to a more common package?
- Does the package manager lockfile show unexpected registry sources?
- Does the dependency run before secrets are stripped from the environment?
Do not stop at vulnerability alerts. Known CVEs are one signal. Supply-chain review needs behavior, provenance, and pipeline context.
Release and incident questions
Release security questions connect preventive review to response. That changes the conversation because the same evidence that blocks a risky change can shorten an investigation later.
Ask:
- Which workflow produced this artifact?
- Which commit, dependency set, and runner produced it?
- Was the artifact signed, and by what identity?
- Did any package execute install-time code during the build?
- Were secrets available to the build job?
- Can we reproduce the artifact from source and lockfiles?
- If compromise is suspected, which downstream systems trusted this artifact?
What breaks in practice is the handoff between proactive and reactive work. Security review finds risks before merge. Incident response needs lineage after damage. The same question model should support both.
Where vu1nz.com fits
Use automation where humans are slow
vu1nz.com is built for teams defending CI/CD pipelines and software supply chains from modern attacks. The product fit is straightforward: automate the evidence collection and first-pass checks that humans are bad at doing repeatedly.
A scanner can inspect workflow permissions, dangerous triggers, self-hosted runner exposure, newly added packages, suspicious install behavior, and package ecosystem risk signals. That does not eliminate security engineering. It gives security engineers a cleaner starting point.
If your team is building this into pull request review, vu1nz.com focuses on catching CI/CD workflow vulnerabilities and package supply-chain risk before they merge.
Keep humans on architecture decisions
Humans should still decide architecture tradeoffs: whether a release workflow needs elevated permissions, whether a self-hosted runner is justified, whether a package is acceptable for a regulated service, and whether an exception is worth the risk.
The best workflow is not fully automated approval. It is automated evidence plus human ownership for the decisions that actually require context.
That is the point of using a security question example correctly. You are not creating paperwork. You are encoding where risk enters the delivery system and deciding what the system should do about it.
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. Use a security question example as the starting point, then enforce it where code actually changes. Try vu1nz.com.
Catch the next supply-chain attack on the PR that adds it.
14-day free trial · no card required