GitHub Actions Security Best Practices Quiz Quiz

Explore essential security best practices in GitHub Actions with this quiz designed to improve your workflow protection strategies. Enhance your understanding of secrets management, permissions control, workflow configuration, and vulnerability mitigation in CI/CD pipelines.

  1. Least Privilege Principle

    Which approach best follows the principle of least privilege when assigning permissions to a workflow that uploads build artifacts?

    1. Grant read and write permissions to all repository resources.
    2. Allow unauthenticated users to trigger the workflow.
    3. Grant only the minimum required permissions for uploading artifacts.
    4. Assign administrator permissions to the workflow.

    Explanation: Granting only the minimum required permissions ensures that the workflow cannot perform unwanted actions, following the principle of least privilege. Assigning administrator or broad permissions (such as full read and write across the repository) increases risk and potential abuse. Allowing unauthenticated users to trigger workflows exposes vulnerabilities. Only the correct choice upholds security without unnecessary access.

  2. Handling Secrets Securely

    In managing sensitive values such as API keys for use within workflows, which method offers the most secure storage and usage?

    1. Store them in the repository’s secrets manager.
    2. Store them in the workflow file as environment variables.
    3. Include them in the README file for documentation.
    4. Commit them to a public branch for easy access.

    Explanation: The repository’s secrets manager encrypts and masks sensitive values, keeping them secure and inaccessible to unauthorized users. Storing secrets directly in workflow files or documentation exposes them to anyone with repository access. Committing secrets to a public branch significantly increases risk. Only the repository’s secrets manager is designed for secure handling of credentials in workflows.

  3. Preventing Unauthorized Workflow Triggers

    What is a recommended way to prevent untrusted users from triggering potentially dangerous workflow runs on pull requests?

    1. Allow workflow runs from any fork and branch without approval.
    2. Use default permissions for all contributors.
    3. Restrict workflow runs to specific branches and authorized users.
    4. Disable all status checks for pull requests.

    Explanation: Restricting workflow runs to trusted branches and users minimizes the risk of arbitrary code execution from untrusted sources. Allowing runs from any fork or branch can allow attackers to exploit workflows. Disabling status checks weakens oversight, and using default permissions for everyone can be overly permissive. Restriction provides tailored and controlled security.

  4. Dependency Vulnerability Mitigation

    Why is it important to keep third-party action dependencies up to date when configuring workflows?

    1. Latest versions always add visual improvements.
    2. Older actions can make workflows faster.
    3. Outdated actions may contain unpatched vulnerabilities.
    4. Up-to-date actions are free of licensing requirements.

    Explanation: Using outdated actions risks introducing security holes, as vulnerabilities may be fixed only in newer versions. Visual improvements do not impact security, and there is no evidence that older actions improve workflow performance. Licensing requirements are not guaranteed to change with updates. Thus, updating actions is critical for vulnerability mitigation.

  5. Controlling Workflow File Modifications

    How can you best reduce the risk of unauthorized or malicious modifications to workflow files?

    1. Allow direct commits to the main branch from all contributors.
    2. Encourage contributors to share workflow files in chat.
    3. Require code reviews for workflow file changes through branch protections.
    4. Disable audit logs for workflow changes.

    Explanation: Branch protections and mandatory code reviews ensure that workflow changes are reviewed and approved, reducing the chance of unauthorized or harmful edits. Allowing direct commits from all contributors removes oversight. Disabling audit logs means fewer records in case of an incident, and sharing workflow files informally does not prevent risky changes. Code review enforces accountability and control.