joshjohanning

Fortifying Your Workflows

Slides

• PDF in repo

Sample Code

• Actions allow list as code implementation
• Exporting Actions usage report implementation

joshjohanning

Supercharging GitHub Copilot

Sample Code

• sample mcp server used during demo

Resources / Links

Generic

joshjohanning

# Dependency Review Action
#
# This Action will scan dependency manifest files that change as part of a Pull Request, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
#
# Source repository: https://github.com/actions/dependency-review-action
# Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
name: 'Dependency Review'
on: [pull_request]

permissions:

joshjohanning

Rewriting repository history

Sometimes history rewrites are required in order to migrate repositories into github.com. Several factors can dictate the need to rewrite history of a repository:

• objects larger than 100Mb
• commits larger than the 2GB push limit

Although rewriting history might not be required for your repository to migrate to github.com, you may consider rewriting history for several reasons:

• migrate large objects to LFS
• cleanup previous mistakes or bad practices that caused repo bloat
• remove secrets from repo history

joshjohanning

trigger:
  - main

pool:
  vmImage: windows-latest

variables:
  advancedsecurity.codeql.querysuite: security-extended
  advancedsecurity.submittoadvancedsecurity: true
  

joshjohanning

# Dependency Review Action
#
# This Action will scan dependency manifest files that change as part of a Pull Request, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
#
# Source repository: https://github.com/actions/dependency-review-action
# Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
name: 'Dependency Review'
on: [pull_request]

permissions:

joshjohanning

Organization archetypes

The intention of this document is to provide some guidance and suggestions to customers who are wondering how they should structure organizations and teams in their GitHub Enterprise environment. The idea isn't to give hard and fast rules on which approach is better than the other, but to give examples of when one approach might be preferable to another depending on the use case.

1. A single organization with direct organization membership for repository access (not teams)

          ________________
          |     Org      |
          |    ______    |
          |   |      |\  |

| | Repo | \ |

joshjohanning

    steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@v3
      with:
        name: ipa-output
    # TODO: set up build certificates and provisioning profiles - see note below
    - name: extract ipa
      run: | 
        unzip -q -o -d ${{ runner.temp }}/app ${{ github.workspace }}/$APPNAME.ipa
        rm ${{ github.workspace }}/$APPNAME.ipa

joshjohanning

eval "$(ssh-agent -s)"
pass=$(az keyvault secret show --vault-name josh-key-vault-test --name passphrase --query value -o tsv)

# sudo yum install -y expect

expect << EOF
  spawn ssh-add /home/codespace/.ssh/id_rsa
  expect "Enter passphrase"
  send "$pass\r"
  expect eof

joshjohanning

name: terraform plan # this doesn't show up in ui

on:
  workflow_call:
    inputs:
      runs-on:
        description: Platform to execute on
        type: string
        default: ubuntu-latest
      additional-args: