DEV Community: Rob Bos

Best Blogposts 2023

Rob Bos — Wed, 20 Dec 2023 00:00:00 +0000

layout: post title: Best viewed blogposts of 2023 date: 2023-12-20 tags: [Blog, GitHub, Azure DevOps] —

It’s that time of the year again! Time to look back at the most viewed blogposts of the year. I’m always amazed at the number of views some of these posts get. I’m also amazed at the number of people that find my blogposts useful. I’m glad I can help out!

Here is the overview:

#	Title	Published	Description	Views
1.	2022	GitHub workflows not starting	🙀The most viewed for a reason! When your GitHub workflows are not starting up, there can be quite a few things causing this. Read this post to find out more!	17.2k
2.	2022	GitHub access tokens explained	Personal Access Tokens can be a quick an easy way to test things out, but should not be used in production scenarios for a number of reasons 👺. In this post I explain why and what alternatives there are	6.7k
3.	2020	.NET core: nesting appSettings.json in the IDE	A three year old post that I jotted down for future reference. Seems like other people still have that same need! 🎉	4.5k
4.	2020	GitHub Actions with private runner: deploy to IIS	🔍 Using a private runner for GitHub actions unlocks tons of scenario’s to deploy into your private production environment as well. Some folks thing it’s hard to do so on Windows and a classical setup with IIS. In this post I explain the moving parts in making this happen! IIRC I used the same setup to stop, install, and start Windows Services as well. 🦖🌴	4.2k
5.	2020	Authenticate to Azure DevOps with a Personal access token	Authenticating to Azure DevOps using a personal access token takes a while to figure it out. For future reference I jotted it down. Still helping other folks after 3️⃣ years!	3.5k

Looking at these things is always interesting for me. For the last three years I have been blogging mostly on GitHub, Advanced Security, and some Azure DevOps (mostly on Advanced Security on Azure DevOps). The top post is about a typical scenario that I see a lot of folks struggle with, so I am very happy this post gets found a lot to.

Three of the top five posts are from 2020! That means a lot of folks still have the same need to know this as I did when I wrote the post. This is also the reason why I keep on blogging about these things. It means I can find these things myself, and apparently other folks find them useful as well 🤗.

My top post from 2023 isn’t even in the top 10 of best viewed posts! It’s the post on GitHub Advanced Security on Azure DevOps, where I explain the new features on Azure DevOps that where announced in the beginning of the year. These security features are available for anyone to use since November 2023 (if you need help with it, let me know!).

Blogposts from this year 📝

Looking back at blogging in 2023, I wrote 12 blogposts and shared my lessons learned or how I implemented things for customers. So even though I average a post a month or so, people still are able to find them and use them for their own benefit.

For me the ones I looked at this year that stand out are:

GitHub Advanced Security on Azure DevOps - I’m a fan of Advanced Security, so this functionality becoming available for Azure DevOps is a big win for me.
How to write to the GITHUB_STEP_SUMMARY - Very helpful to have a mental image of the moving parts. Instead of looking at the sparse GitHub docs for this, I refer to my own post almost quarterly at the moment.
GitHub container based action cleanup - I’m a fan of container based actions, but it can be a bit tricky to clean up after yourself in a container based action.
Get alerts from GitHub Advanced Security for Azure DevOps - In the past months I created an extension for Azure DevOps to show alert information in your dashboards, as I was missing that information in the default functionality. This post explains how I you can get those alerts from the REST API yourself (written when the docs were not avaiable yet).

Website stats 📈

For visitor numbers I use Plausible.io and those numbers are publicly available here.

A few of the numbers can be found below:

Dependabot alerts triaging in GitHub

Rob Bos — Sat, 07 Oct 2023 00:00:00 +0000

The GitHub UI displays a couple of helpful tips to use in triaging your Dependabot alerts which are super helpful. Unfortunately the User Interface does not show these filters in the filter bar yet, so I wanted to have a better overview of the filters I could use. I’ve listed them below:

Only show alerts where your code is using the vulnerable calls of the dependency

This is very helpful in triaging the open alerts. Currently in limited preview for certain languages and certain package ecosystems. I hope they will expand this to more languages and package ecosystems.

Instead of wading through all the open alerts where your code might (currently!) not call into the vulnerable part of the dependency code, you can filter down the list of alerts to the things you are calling. Use this filter:

is:open has:vulnerable-calls

Filter on Dependabot auto dismissal

Dependabot now has new functionality to auto dismiss alerts that have low or medium severity. This is a great way to reduce the noise in your alerts list so you can filter on the important issues. You can filter on these alerts with this filter:

is:closed resolution:auto-dismissed

Filter on only runtime dependencies

This is a great way to filter out the development dependencies from the runtime dependencies. This is the case for example when you use NPM as a package manager. You can use this filter to only show the runtime dependencies:

is:open scope:runtimeDo make sure that you are not accidentally publishing to production with development dependencies. This is a common mistake that can lead to security issues, as the files are then still on disk, and could be used as an attack vector.

Filter on vulnerable dependencies where a patch is available

This is helpful to focus on quick wins. Since there is a patch available that fixes the vulnerability, getting these dependencies upgraded can lead to fast results. You can use this filter to only show the alerts where a patch is available:

is:open has:patch

Get alerts from GitHub Advanced Security for Azure DevOps

Rob Bos — Sat, 02 Sep 2023 00:00:00 +0000

GitHub Advanced Security for Azure DevOps (GHAzDo) builds on top of the functionality for GitHub Advanced Security and is giving you extra security tools to embed into your developer way of working. It’s a great way to get started with security in your Azure Pipelines and Azure repos and I’ve written about it before in this blogpost.

Loading the alerts from the API’s

Before starting with the Advanced Security API’s you’ll need to get the ID for the repository you are working with. You’ll need to have the project name and the repository name itself. With that you can make this API call:

https://dev.azure.com/<PROJECT NAME>//_apis/git/repositories?api-version=7.1-preview.1

It will return you the list of repos the token you are using has access to. The repo object will look like this:

{
            "id": "5e5195e1-1b44-4d4b-9310-5d33ee2c4dc",
            "name": "eShopOnWeb",
            "url": "https://dev.azure.com/raj-bos/3651f6f0-74e5-48d7-8ff9-d62ae2464b1/_apis/git/repositories/5e5195e1-1b44-4d4b-9310-5d33ee2c4dc",
            "project": {
                "id": "3651f6f0-74e5-48d7-8ff9-d62ae2464b1",
                "name": "GHAzDo trial",
                "url": "https://dev.azure.com/raj-bos/_apis/projects/3651f6f0-74e5-48d7-8ff9-d62ae2464b1",
                "state": "wellFormed",
                "revision": 141,
                "visibility": "private",
                "lastUpdateTime": "2023-07-26T18:51:26.227Z"
            },
            "defaultBranch": "refs/heads/main",
            "size": 62610330,
            "remoteUrl": "https://raj-bos@dev.azure.com/raj-bos/GHAzDo%20trial/_git/eShopOnWeb",
            "sshUrl": "git@ssh.dev.azure.com:v3/raj-bos/GHAzDo%20trial/eShopOnWeb",
            "webUrl": "https://dev.azure.com/raj-bos/GHAzDo%20trial/_git/eShopOnWeb",
            "isDisabled": false,
            "isInMaintenance": false
        }

From this you need the “id” field of the response. That can then be injected into the next API call:

https://advsec.dev.azure.com/<PROJECT NAME>/<REPO NAME>/_apis/AdvancedSecurity/repositories/<REPO ID>/alerts?top=50&orderBy=severity&alertType=3&ref=refs/heads/main&states=1

The filtering options determine the response you will get back:

Param	Description
top	The number of alerts you want to get back.
orderBy	The field you want to order the results by.
alertType	The type of alert you want to get back. 1 = Dependency, 2 = Secrets, 3 = Code scanning
ref	The branch you want to get the alerts for, only needed when looking at code scanning alerts
states	The state of the alerts you want to get back. 1 = Open, 2 = Closed

You can also leave the alertType away from the url to get all alerts in one go. Do be aware that it will result in a different value for the alertType in the response, instead of the numbers listed in the table above:

Value	Type
code	Code scanning alert
secret	Secret scanning alert
dependency	Dependency alert

Cleaning up files changed by a GitHub Action that runs in a container

Rob Bos — Wed, 21 Jun 2023 00:00:00 +0000

A common issue we see with self-hosted runners is that they can leave behind files that were created or modified by the action. This is because the action runs in a container and the container is using a root user to do its work.

The GitHub documentation says to run the the runner service as root as well, to have the most compatibility with most runners. This is not a good idea, as it can lead to security issues, so a lot of people run the runner service as a non-root user. This can lead to permission issues when the action touches files in the workspace directory that get’s mounted.

Photo by Aakanksha Panwar on Unsplash

Examples

One common example is the super-linter action. Depending on the checks that run, it can touch files on disc that then get owned by the root user.

Another example is running the entire job inside of a container, with using the keyword container on the job level:

jobs:
  build:
    runs-on: self-hosted
    container: ubuntu:22.04
    steps:
      - uses: actions/checkout@v2
      - run: echo "Hello World"

The checkout action will create a .git directory in the workspace directory with the repo contents, which will be owned by the root user as the ubuntu-22.04 container runs as root. The job itself will complete just fine, but the next time you run another job for this repository on the same runner, the checkout action will try to cleanup the $GITHUB_WORKSPACE directory to get a clean starting point, and will fail with a permission error since the job is not running as root, but as the non-root user the runner service is executing under.

There are multiple ways to tackle this issue:

Prevent it from happening: Run the runner service as root and run the job as root as well. This is recommended by GitHub to prevent this from happening, that is how the service has been designed. Most people I talk with do not agree since the user has to much permissions and it can lead to security issues.
Change the action to not run as root, which is not realistic when using actions from the public marketplace.
Get the user to cleanup inside of the container, or add a cleanup action in their job.
Add cleanup configuration on the container level configuration in the runner
Add cleanup configuration on the runner configuration itself
Do not run the container with any persistence: run as ephemeral, where the runner is alive for a single job execution, and then gets completely deleted and cleaned up so there is no reuse.

I’ll go over the last 4 options in this post.

Get the user to cleanup inside of the container, or add a cleanup action in their job.

You could hunt for the jobs that cause this issue, and ‘ask’ the user to add a cleanup action in the job itself. There is for example a cleanup action available in the marketplace that runs in a container that uses root, and that cleans up the workspace directory. This is not a good solution, as it requires a lot of manual work, and you will have to keep track of the jobs that cause this issue. The following options are probably manageable in a better way.

Add cleanup configuration on the container level configuration in the runner

You can configure the runner with specific customization commands that get executed before and after the job, as well as other options:

prepare_job: Called when a job is started.
cleanup_job: Called at the end of a job.
run_container_step: Called once for each container action in the job.
run_script_step: Runs any step that is not a container action. See the entire configuration and examples here. This is rather complex and more suited for configuring sidecars or other complex scenarios. I prefer to use the next option.

Add cleanup configuration on the runner configuration itself

By setting 2 environment variables before the job starts, you can run specific scripts before and after the job starts. The completed job can then be a docker run command that mounts the $GITHUB_WORKSPACE and cleans everything up while running as root. This is the easiest option in my opinion:

ACTIONS_RUNNER_HOOK_JOB_STARTED: The script defined in this environment variable is triggered when a job has been assigned to a runner, but before the job starts running.
ACTIONS_RUNNER_HOOK_JOB_COMPLETED: The script defined in this environment variable is triggered after the job has finished processing. Find more information in the documentation here.

Do not run the container with any persistence

The best advice is to always start runners as ephemeral, where the runner is alive for a single job execution, and then gets completely deleted and cleaned up so there is no reuse. You will need to provide a mechanism to cleanup the Virtual Machine or Container setup where you execute the runner on. The best method I’ve found is to use Actions Runner Controller where the runner is executing inside of a container that gets deleted after the job is done. This will prevent any data to linger around on the runner as well, and gets you a clean execution environment every time.

There might be some valid reasons to still have a persistent runner, but I would recommend to use ephemeral runners as much as possible.

Writing to the $GITHUB_STEP_SUMMARY with the core npm package

Rob Bos — Thu, 08 Jun 2023 00:00:00 +0000

Every time I need to write to the GITHUB_STEP_SUMMARY in GitHub Actions from the actions/github-script action (or from Typescript), I need to search for the blogpost that announced it’s existence. So I’m writing this blogpost to make it easier for myself to find it a lot easier, including some working examples.

Photo by Markus Winkler on Unsplash

The code for the summaries lives in the actions/core package on npm, but figuring out how to use it can be a bit hard. The only example I’ve seen is in the blogpost I mentioned.

  import * as core from '@actions/core' 

  await core.summary
  .addHeading('Test Results')
  .addCodeBlock(generateTestResults(), "js")
  .addTable([
    [{data: 'File', header: true}, {data: 'Result', header: true}],
    ['foo.js', 'Pass ✅'],
    ['bar.js', 'Fail ❌'],
    ['test.js', 'Pass ✅']
  ])
  .addLink('View staging deployment!', 'https://github.com')
  .write()

This does a lot of things at the same time, but we get the general idea that you can:

add headings
add code blocks
add tables
add links And at the end you need to write the summary itself, which will be added to the file in the GITHUB_STEP_SUMMARY environment variable.

Working with the table output

There are no methods to break the table into chunks, like:

Add a header
Add a row

The only method there is, is adding the table in one go, with each row as an array of objects, and some configuration in the first row as that will define if the cell is a header or not. So assuming you have an array of results that you want to show, you can convert that array with properties into an array of rows, with each property value being an item in the row array.

The interesting thing I ran into, is that the row cells must be a string. Sending in integers for example does not work. Take the following example:

await core.summary
            .addHeading('Example')
            .addTable([
                        [{data: 'Topic', header: true}, {data: 'Count', header: true}, {data: 'Public', header: true}],
                        ['foo.js' , "1", "2"],
                        ['bar.js' , '3', '4'],
                        ['test.js', 100, 200]
                      ])
            .write()

In this example, all rows will be added to the summary, and as long as the content is a valid string, it will be shown in the table as well. In this example, the values in the last row are integers, and they will be not visible in the table.

A full example of creating the header array with hardcoded cells, and then adding the rows from an array of objects can be seen below. Here I have an array stored as output in a previous step, so I read that file and map it (as string values!) to an array containing the rows. The next step is to join the two arrays (header + summary) and pass that to the addTable method.

- name: Show information in the GITHUB_STEP_SUMMARY
    uses: actions/github-script@v6
    env:
    summaryFile: $
    with: 
    script: see below in other markup for better readability


        const fs = require('fs')
        const summary = fs.readFileSync(process.env.summaryFile, 'utf8')

        // make the heading array for the core.summary method
        const headingArray = [{data: 'Topic', header: true}, {data: 'Count', header: true}, {data: 'Public', header: true},{data: 'Internal', header: true},{data: 'Private', header: true}]

        // convert the summary array into an array that can be passed into the core.summary method
        const summaryArray = JSON.parse(summary).map(t => [t.name, t.count.toString(), t.public.toString(), t.internal.toString(), t.private.toString()])

        // join the two arrays
        const tableArray = [headingArray, ...summaryArray]

        await core.summary
                .addHeading(`Topics used on repos in the [${process.env.org}] organization`)
                .addTable(tableArray)
                .write()

GitHub Advanced Security for Azure DevOps

Rob Bos — Tue, 23 May 2023 00:00:00 +0000

Microsoft is bringing some of the GitHub Advanced Security tools to Azure DevOps. I have been playing with it for a while and they have presented the latest state at Microsoft Build 2023, which includes a Public Preview!. That means you can try it out yourself, and I can finally share my experiences with you! Since I teach a lot people on how to use this on GitHub, you can find some of the differences between the two implementations in this post as well 😉.

Photo by Adi Goldstein on Unsplash

What is GitHub Advanced Security?

GitHub Advanced Security (GHAS) is a set of tools that help you secure your code and your pipelines. It includes the following tools:

Code scanning
Dependabot / Dependency scanning
Secret scanning

If you want to dive deeper into that functionality, check out my LinkedIn Learning Course here.

Dependabot / Dependency scanning

Scans you repository for known manifest files, like package.json, and checks if there are any vulnerabilities in the packages you are using. It will then create a pull request to update the package to a newer version that does not have the vulnerability. It can also automate creating pull requests for version updates as well.

Secret scanning

Scans your repository for known secrets, like passwords, and notifies you if it finds any. It will also notify you if you push a commit that contains a secret. It will also scan your pull requests for secrets and notify you if it finds any.

Code scanning

Scans your code for known vulnerabilities using CodeQL (or another Static Application Security Tool, aka SAST). It can also scan your pull requests for vulnerabilities and notify you if it finds any.

GitHub Advanced Security for Azure DevOps

Microsoft is bringing the features from GHAS into Azure DevOps as customers have been asking for this for a while. It’s an example of the way they operate both products now, since the new features will get build for GitHub first, and if it makes sense, they might build some of these features into Azure DevOps as well.

You can see the synergy here as well as of course: any known secret scanning patterns from GHAS can also be used in Azure DevOps, since they can share that between the companies.

How to get started with GitHub Advanced Security for Azure DevOps

After enabling the feature (can be done on a repo by repo basis), you will get a new ‘Advanced Security’ tab in your repository menu. This will show you the results of the scans that have been done on your repository.

After enabling the feature you will get some extra menu options left and right, as well as extra tasks for your Azure Pipelines.

Turning on Secret scanning

Secret scanning is turned on automatically when you turn on Advanced Security. It will start a background job that will scan your repository for secrets. It will also scan you repos entire history: all commits and branches will be checked, for known secret patterns. One additional feature is ‘push protection’. This will prevent you from pushing a commit that contains a secret. This is a great feature to prevent secrets from being pushed to your repository and ‘stop the leak’ of new alerts flowing in.

Using dependency scanning

To get started with Dependency scanning you need to inject it into a pipeline. This can be done by adding the following task to your pipeline:

  - task: AdvancedSecurity-Dependency-Scanning@1

The next time this pipeline will run, it will scan you repository for known manifest files, like .csproj for C# projects, or package.json for NodeJS projects. From those manifest files it gathers the information about the packages you are pulling in, and can check the underlying ecosystem for the dependencies of those packages as well (libraries build on other libraries as well). It will then check if there are any vulnerabilities in the packages you are using. You can check each package you use, and all of their dependencies as well, with their version numbers against the National Vulnerability Database (NVD from the NIST institute). Also registered in the NVD is which version is no longer vulnerable (if applicable).

On GitHub that information is used to create a pull request to update the package to a newer version that does not have the vulnerability. It can also automate creating pull requests for version updates as well. This is not available for GitHub Advanced Security for Azure DevOps. I do expect this will be added later, but for now you will have to create the pull requests yourself.

In the alert you will get information on the package version that you use, the first non-vulnerable version, as well as the type of vulnerability, so that you can learn on the type of attack vector for this alert.

Using Code Scanning

For enabling Code Scanning you need to inject CodeQL into an Azure Pipeline as well (other SAST tools will work as well, as long as they upload a SARIF file):

    - task: AdvancedSecurity-Codeql-Init@1
      inputs:
        languages: 'csharp'

    - task: AdvancedSecurity-Codeql-Autobuild@1

    - task: AdvancedSecurity-Codeql-Analyze@1

    - task: AdvancedSecurity-Publish@1

There are a couple of steps to note here:

Init will create a local, empty database that will be filled with all the code paths your code is taking (for example: Method A is calling Method B). You also feed it one of the supported languages (C#, Java, C/C++, Python, JavaScript/TypeScript, Go, or Ruby).
The auto-build step will try to build you application, based on known patterns for the language you have selected. Sometimes the auto build fails for certain projects, you can then use your own build steps in its place.
With Analyze you run all the CodeQL queries against the database that was created in step 1. This will also create a SARIF file that contains all the results of the queries (if a query has a result, it will become an alert).
The Publish step will actually upload the SARIF file to the Advanced Security service, which will then show you the results in the UI.

The queries that will be run can be found in the CodeQL repository on github.com. There is a default set with low noise ratios, but you can also use extended queries by configuring them this way:

    - task: AdvancedSecurity-Codeql-Analyze@1
      inputs:
        querysuite: 'security-and-quality'

Note that in Azure DevOps you configure this on the `Analyze` task where as you do that in GitHub in the `Init` step.

Do be aware that adding more extensive queries will increase the duration of the pipeline, as well as the amount of alerts you will get: the extended queries have a bit more noise and potentially also more false positives. For example from my demo application I went from 4 normal alerts to 7 extra alerts when I added the extended queries from security-and-quality.

The advise is to run these queries at least on a pull request, as well as on a schedule: the community who builds these queries is super active (150~200 pull requests a month in that repository), so you will get new queries that might find vulnerabilities in your code.

When a result of the queries is present, you will see those come by in the logs as well:

From the upload of the SARIF file you will then get the alerts generated in the Advanced Security overview:

When you open up an alert you get more information on the detail page:

From here you can again learn more about the vulnerability found, with links back to the Common Weakness Enumeration number (CWE) on the Mitre site.

Addressing the alerts

To fix the alerts you will need to actually fix the finding it self. There is not yet a way to dismiss the alerts in Azure DevOps (something we do have on the GitHub side).

Fixing secret scanning alerts

For secret scanning the UI currently shows the warning that you need to treat this secret as a leaked value, and fixing can only be done by revoking the secret.

Since there is no way to dismiss this alert through the UI yet, the only way to get rid of this alert is to rewrite the history of the repository so that the commit is no longer in the history. I expect that dismissing alerts will be added in the future, but for now this is the only way to get rid of the alert.

Fixing dependency scanning alerts

To get rid of a dependency scanning alert you will need to create a pull request to upgrade the dependency to a version that is no longer vulnerable. When the detection scan runs again, the alert will get closed. You have a link back to the pipeline that detected that the vulnerable dependency is no longer present:

Addressing code scanning alerts

Fixing Code Scanning alerts is a bit more involved, as you will need to actually fix the code that is causing the alert. After fixing the issue, the next scan will close the alert and will link back to the scan that closed the alert. From it, you can find the commit that fixed the issue as well, so you have that end-to-end traceability.

Note that currently you cannot exclude code from the CodeQL scanning (on GitHub you can). That also means that your unit test suite for example, will get scanned as well, with a good change it finds some issues there as well (I had the same issue with my test project).

Dashboarding

For an overall overview of how you are doing across the entire project or organization, you’ll have to look at Microsoft Defender for DevOps, which is a tool in Microsoft Azure. Since I don’t have Defender integrated yet (I think you need a feature flag to enable that), I don’t have any screenshots yet. I will add them when I have the access!

The integration does make sense from the Azure perspective and integrate it in the tools folks on Azure Cloud use. But if you only use Azure DevOps, then I would expect an overview to find repeat patterns or dependencies in you Azure DevOps Organization as well. I would not be surprised if they add that overview somewhere in the future.

Summarizing

Overall, most of the initial features are already in, with definitely some different choices made comparing it with GitHub’s implementation (for example dashboarding). You can see it is early days, but I expect the rest of the features / finetuning will happen fast, now that the initial part has been integrated (which is often the most work).

We now have good security features integrated into Azure DevOps, right into the developer experience, which is where this needs to land in my opinion: with the folks who can act on the findings and fix them early on in their process. I hope they integrate the dependency-review-action equivalent for Azure DevOps next, so developers will also be enabled to stop the leak (of incoming vulnerable dependencies).

If you want to know more or have questions, use the comments below!

How Copilot/AI helps me in my daily work

Rob Bos — Mon, 24 Apr 2023 00:00:00 +0000

How Copilot and AI helps me in my daily work

During an innovation day at work, I needed to generate extra code and a new application. I wanted to check out the newly released Deployment Protection Rules that can help you with protecting when a job in GitHub Actions can roll out your application to an environment.

Deployment protection rules need a new GitHub App that can be triggered when an environment is targeted. That App can then run its own checks and report back the status to GitHub with a callback webhook.

To get started I needed a new GitHub App that can receive the webhook from GitHub. Since I already have an Azure Function App up and running, I thought to add another HttpTrigger function to it, so I could log the payload and learn from that (the payload is not documented yet).

Image generated with Craiyon.ai using the following prompt: `sketched photo with some realism of an AI generating code`.

Usual flow

Normally I would start with searching for the things I need: some documentation for hosting an endpoint to receive the webhook payload, search for creating an app to handle the user login, etc. This can easily take days tinkering around to get things to where it is good enough for a POC. Instead, I used AI tools to help me, and had things up and running in a few hours.

Step 1: Create a new Azure Function

I knew I needed an HttpTrigger and was about to search for it’s declaration, when I remembered I was already testing out GitHub Copilot for Chat, which is in technical preview so I cannot say to much about it. I asked Copilot to write the function definition for me and sure it enough: it proposed the right code, including logging of the incoming payload. Using that code I could publish the function and configure it as a webhook from a new GitHub App.

The logs show that payload sends in the normal information you would expect, like the context for the trigger (in this case workflow_dispatch was triggered by my user account) and the callback URL that can be used to report back the status of the check. The callback has the following form: https://api.github.com/repos/{OWNER}/{REPO}/actions/runs/{RUNID}/deployment_protection_rule.

That means it uses a well defined url, so I can just call that as the GitHub App for testing to see if it works. I’ve configured the Deployment Protection Rule with my new GitHub App based on an existing workflow (Copilot still helped here left and right), and tested it in a workflow to call the callback url.

Step 2: Create a new node.js app for user configuration

An important part for my setup with the GitHub App will be to have the user configure settings for their environment. So that means I need to have a way to host an app that can do the OAuth flow with GitHub and store the settings in a database.

I’m not a JavaScript developer who knows exactly how to get started, but I do have AI tools that can help me with that. The easiest option I have and that is free to use, is the Bing integration in Edge. Here is my prompt: How can I get started with a simple webapplication based on node that uses GitHub authentication for the user to login and then retrieve information as that user:

Here is a part of the resulting app:

It even had the steps in there to store the configuration settings from the GitHub App in the .env file. I could just copy that example and add the code to the app.

There was an error running the app locally, but I could just copy the error message and search for it following the same conversation on Bing. The first result was the right answer, so I could just copy that again (npm install express-session) and add it to the app.

You can see the working redirect for the user authentication below:

Generated code

The generated was not perfect: it picked up some things from the code it was trained on that can be improved. GitHub Copilot should prevent this kind of security issues when generating code, but I used Bing’s AI to generate this part of the code.

This proves the point that even when using AI to help you generate code, setting up security pipelines is still very important. Luckily GitHub has made Advanced Security features available for free for public repos, allowing me to scan the code using CodeQL:

If you want to learn more about GitHub Advanced Security, then check out my LinkedIn Learning Course on it: LinkedIn Learning.

I could then use the generated code to get started, and improve it to make it more secure using the security tools available as well.

Conclusion

And with that, most of my setup (the new Azure Function and the new node.js app) was done with me writing minimal amount of code, and still getting everything to work as I wanted.

Do be aware that I have enough experience with these topics to both know what to look for, and how to spot / find / debug errors in my code. I’m sure that if I was a beginner, I would have had a lot more questions and would have needed to do a lot more research to get to the same result.

I’m really excited to see what the future holds for Copilot and AI in general. I’m sure it will help me and many others to get more done in less time.

Enabling CodeQL on GitHub Enterprise Server

Rob Bos — Fri, 24 Feb 2023 00:00:00 +0000

To enable CodeQL on GitHub Enterprise Server you need to make sure you have GitHub Actions setup and running, including your own set of self-hosted runners. You can read more about that in my previous post here.

From that point you can get started to enable CodeQL. Of course, you’ll need to have it enabled in your license, and upload that license file to your server as well. Enabling starts at the appliance level, where you need to enable the code scanning and secret scanning features from the management console.

Photo by Barn Images on Unsplash

The default workflow that CodeQL will propose links to the github/codeql-action action, of which a static copy is installed with each Enterprise Server update. This organization is hidden by default, but you can navigate to it with the direct link. The issue here is that these action repos (github/dependabot-action and all repos in the actions org) only have the source code linked and updated with each Enterprise Server update. Since the CodeQL bundle is stored as a release asset, it is missing from the appliance. The bundle contains all CodeQL queries, including the security-extended and security-and-quality query types.

Syncing the CodeQL bundle

Normally we’d use the actions-sync tool to update the actions on the appliance with the latest version on github.com. Unfortunately that tool does not sync any release assets. For syncing the release assets, we need to download the latest release of the codeql-action-sync-tool.

After downloading the codeql-action-sync-tool, you need to make sure you have write access to the github organization. By default you do not have it, so you cannot write to the release assets or anything else in this org. That means we need to promote the user that will execute the syncing to an owner of the github org.

To do so, you need to call the ghe-org-admin-promote command line utility from a remote shell on the appliance:

ghe-org-admin-promote -u USERNAME -o ORGANIZATION

Now we can call the codeql-action-sync-tool to download the latest version of the CodeQL bundle and upload it to the github/codeql-action repo. This tool will also update the github/codeql-action repo with the latest version of the action code.

You can run it with this command:

codeql-action-sync-tool sync --force \ 
 --destination-url https://enterprise-server-url.com
 --destination-token <PAT> \
 --source-token <PAT> # prevents ratelimiting

Of course, the machine that is running this will need to have access to github.com, as well as the Enterprise Server. The --source-token is optional, but it will prevent you from hitting the rate limit on github.com.

Running CodeQL efficiently

Now that we have the CodeQL bundle on the appliance, we can start using it. The first thing you’ll notice is that the CodeQL bundle is quite large. The Linux zip file alone is 500Mb, which is quite a lot for a GitHub Action. The release asset appropriate for the OS of the runner is downloaded for each run. If you are using ephemeral runners (which you should!), this means that the CodeQL bundle is downloaded for each and every run. Given that this workflow is configured by default to run on every push, pull request as well as on a schedule (once a week), it can take up quite the bandwidth and thus hammer your appliance.

The action follows the normal setup for GitHub Actions to check for the well known folder runner.tool_cache, which is stored in ‘/opt/hostedtoolcache/’. If it can find the bundle in that folder, it will use that. If it cannot find it, it will download the appropriate release asset.

That means that we can prep our runners by copying the CodeQL bundle to this location. This will prevent the bundle from being downloaded for each run. The folder is used by including the CodeQL bundle release version and date: /opt/hostedtoolcache/CodeQL/2.12.1-20230120/x64/codeql/codeql.

Priming that location will significantly lower the download pressure on your appliance, and speed up the execution of the CodeQL workflow.

Making the case for GitHub's Secret scanning

Rob Bos — Sun, 22 Jan 2023 00:00:00 +0000

After scanning the GitHub Actions Marketplace for the security of those actions (read that post here) I was curious to see what happens if I’d enable Secret Scanning on the forked repositories. I regularly teach classes on using GitHub Advanced Security (where secret scanning is part of) and I always tell my students that they should enable secret scanning on their repositories. I even have a course on LinkedIn Learning about GitHub Advanced Security in case you want to learn more about it.

What is GitHub Secret Scanning?

Secret scanning is part of the GitHub Advanced Security offering if you have a GitHub Enterprise account, but for public repos it is free to use (and enabled by default). GitHub scans the repository (full history) and issues and pull requests contents to see if it detects a secret. The detection happens based on a set of regular expressions shared by GitHub’s secret scanning partners (over 100 and counting). If a secret is detected, GitHub will notify the repository owner as well as the secret scanning partner. Depending on the context (public repo or not for example), the secret scanning partner can decide to revoke the secret immediately, which I think most partners do.

This functionality is so good and fast, that I routinely post my GitHub Personal Access Tokens to GitHub issues during my trainings, to show the power of secret scanning. Usually I already have an email and a revoked token before I finish explaining what is happening in the background.

Photo by Kristina Flour on Unsplash.

Analyzing the actions repositories.

In my GitHub Actions marketplace scan, I have the repositories of 14k actions forked into an organization, so I can enable secret scanning and see what I get back from secret scanning. Since all Action repositories on the marketplace are public, any secret that is found has been found before, so I expect all these secrets to already have been revoked before.

Overall results: Found [1353] secrets for the organization in [1110] repositories (out of 13954 repos scanned). Here is a top 15 of most found secrets to see what is being found:

Secret scanning alerts

|Alert type|Count| |—|—:| | GitHub App Installation Access Token | 692 | | Azure Storage Account Access Key | 155 | | GitHub Personal Access Token | 120 | | Amazon AWS Secret Access Key | 50 | | Plivo Auth ID | 40 | | Amazon AWS Access Key ID | 40 | | Google API Key | 34 | | Slack API Token | 31 | | Slack Incoming Webhook URL | 27 | | Atlassian API Token | 22 | | Plivo Auth Token | 16 | | GitHub SSH Private Key | 12 | | Amazon AWS Session Token | 12 | | HashiCorp Vault Service Token | 11 | | PyPI API Token | 10 |

With all the news recently about credential leaking and malicious actors using these secrets to do bad things, I think it is very important to enable secret scanning on your repositories! Having this data really shows the power of GitHub and its secret scanning partners.

Analyzing the results

I wanted to get these results to get a feel for the amount of things secret scanning would find. I my opinion, the maintainers of these actions have a high level of understanding Git and GitHub, so you’d expect a relative low number of secrets being found. Still, 1110 repositories out of 13954 repos is 7.9% off all repos where secrets have been found. This shows how easy it is to accidentally commit secrets to a repository. Even in my own repos, a secret was found (a GitHub Personal Access Token even) that I accidentally committed in an environment file! And that while I teach people on these things!

I think this is a good number to show to my students and customers to make the case for enabling secret scanning on their repositories. Even folks with a high level of understanding, will still make mistakes and secret scanning will help by finding them for you, every time you make a change to your repository.

Adding OSSF scorecard action to your repo

Rob Bos — Thu, 08 Dec 2022 00:00:00 +0000

Recently I’ve started to add the OSSF scorecard action to my (action) repositories. This is a GitHub action that will run the OSSF scorecard checks against your repository to see if you are following best practices, like having a security policy, using a code scanning tool, etc. Using this badge can give your users a quick overview of the security of your repository.

Scorecard action

The scorecard action will do three things (if you use the default settings):

Analyze your repository for the checks
Upload the results to the GitHub Security tab (using a SARIF file)
Upload the results to the OSSF API (A web API that you can even host yourself) With the data uploaded to the OSSF API you can then retrieve a badge with your latest score and show that on your repository:

Scoring

The action checks your repository against several checks and then calculates a score for each check on a scale of 0 to 10. Based on the risk for that check, the score is then multiplied with a weight. The final score is the average of all the weighted scores. The higher the score, the better.

Some of the checks that are executed are:

Branch-Protection: Is branch protection enabled for the default branch?
Are GitHub Action versions pinned to SHA hashes, following best practices?
Is the repository using a code scanning tool? Note that this check currently only supports CodeQL and SonarCloud
Is there a security policy defined?
Is there a definition file for Dependabot?

Setting it up

Setting is up is as easy as going to the OSSF scorecard action repo and copy the workflow example. Add that to you a new workflow file in your repo and run it from the default branch (usually main). After the first run, you can add a link to your README.md file to show the badge.

The result will be a badge showing the latest score:

Code scanning alerts

The default workflow also uploads the check results as a SARIF file to the Code Scanning Alerts that you can find on the Security tab of your repository. Each check can give one or more results, so you will get an alert for each result. That way you can fix the issues one by one.

Even better is that most of these alerts will give you actionable suggestions on how to fix the issue. For example, the alert above will give you a link to the Step Security Application that can analyze your repository and give you a pull request with the changes to fix the issue. They focus on three things:

Restrict permission for the GITHUB_TOKEN
Add security agent for GitHub hosted runner (Ubuntu only)
Pin actions to a full SHA hash

Restrict permission for the GITHUB_TOKEN

One of the best practices is to always indicate what permissions you want to allow for the GitHub token that will be used in your workflow. The default setting is to permissive: it is read and write for everything in your repo. I’ve been advocating that people always make this read-only at the organization level.

Since you cannot see what the organization permissions are, it’s a best practice to always specify the rights. You can add it to the top of your workflow file:

permissions: read-all

And now you can override it at the job level if you need to. For example, if you need to push to a branch, you can add write to the contents permission:

jobs:
  build:
    permissions:
        contents: write
    runs-on: ubuntu-latest
    steps:
     # etc

Add security agent for GitHub hosted runner (Ubuntu only)

This setting is something I want to look into more. It seems that you can add a security agent to your GitHub hosted runner (available only for Ubuntu). It’s an extra product from Step Security which is available for free. It will analyze the network traffic in the job and log that in their system. After a couple of runs they know what kind of traffic is to be expected, and then you can convert that to basically a firewall rule. Any violations will then be logged and blocked. This can give you a better perimeter defense (as by default all traffic is allowed).

Definitely something to look into more!

Pin actions to a full SHA hash

The last option is to pin your actions to a full SHA hash. This is a best practice that I’ve been advocating for a while. It’s a bit more work, but it will make sure that your workflow will not be affected by a malicious actor pushing a new version of an action. What I really like is that this setting will analyze your workflow file (either pasted in or just all workflows in your public repo) and then suggest the SHA hashes of the actions, by looking at their latest version! Even better, they store the latest version in the comment next to the SHA hash, so you can understand where the hash comes from. If only Dependabot understood that comment and would update it in their version update PRs… 🤔!

Examples for calling the GitHub GraphQL API (with ProjectsV2)

Rob Bos — Mon, 28 Nov 2022 00:00:00 +0000

Recently we had to call the GitHub GraphQL API for creating a new GitHub Project (with V2). Since this can only be done with the GraphQL API, we had to figure out how to do this. We found little bits and pieces of information, but no complete example. So we decided to write one ourselves. I hope this helps you as well.

ProjectsV2 GitHub GraphQL API

The new GitHub Projects simply do not have a REST API at the moment, so you are forced to use the GraphQL API. As an extra challenge, the GraphQL API requires a new set of ID’s for these calls.

Logging in

If you are not careful, then the first hurdle will be to login with the right scopes. I’m going to use the GitHub CLI in this post, but you will need to make sure you have the right scopes for this with manual API calls as well. Logging in with just the normal gh auth login call is not enough in this case. Add the project scopes to your call:

gh auth login --scopes "project"

Getting the new ID’s

Now we can start making the calls to the GraphQL API. Since this API with ProjectsV2 needs the new ID’s, make all calls like this to get the new ID’s:

# powershell:
$response = $(gh api graphql -H "X-Github-Next-Global-ID: 1" -F query=$query | ConvertFrom-Json)

Now we can call the API with the current login to get the new ID for this login:

$query = "query { viewer { login, id } }"
$response = $(gh api graphql -H "X-Github-Next-Global-ID: 1" -F query=$query | ConvertFrom-Json)

Need to get the ID from an organization? Use this query:

$query="query { organization(login: ""$organizationName"") { id, name } }"

Working with ProjectsV2

Now we can start loading the existing projects for an organization:

$query="query { organization(login: ""$organizationName"") { projectsV2(first: 100) { edges { node { id } } } } }"

And we can create a new project:

$query="mutation (`$ownerId: ID!, `$title: String!) { createProjectV2(input: { ownerId: `$ownerId, title: `$title }) { projectV2 { id } } }"

If you want to see the full script, you can find it here.

Working with GitHub secrets without admin rights

Rob Bos — Fri, 11 Nov 2022 00:00:00 +0000

I was giving a training today on GitHub Actionshttps://github.com/features/actions and learned something new! One of the attendees asked about being able to read and write to Repository Secrets without having admin rights. I had never tried this before, but it turns out it is possible!

The premise:

To be able to create actions on the repository you need to have Admin access to the repository: otherwise the UI will not be visible, since it is under the repository settings. For organization level secrets you need Admin access to the organization level.

That also means that team members that do not have Admin access, cannot SEE the repository secrets in the UI. They always had to rely on the examples in other workflow files to see what type of secrets were available. Today I learned that any user with write access to the repository can also create, update, and delete a secret. Even if they cannot see it in the UI, they can use the API to manage the secrets. It would be great if GitHub updates the UI to make these kinds of information available to all users that need it (write and maintain). Something similar happens with available GitHub Self-hosted Runners (information is not available for non-admins).

Photo by Markus Winkler on Unsplash

The solution:

If you have write access to the repository, you can use the API to create, update, and delete secrets. You can use the GitHub CLI to do this, or you can use the GitHub REST API.

There is also an API for Environment secrets that work the same way: GitHub REST API.

The GitHub CLI is a great tool to use, since it is easy to use and it is cross-platform. You can install it on Windows, Linux, and Mac. For maintaining the repository secrets, there is a native call in the CLI that you can use: link.

  # list all secrets for the current repo
  gh secret list

For environment secrets there is no native call in the CLI, but you can use the REST API to list the secrets. You can use the following command to list the environment secrets:

    # list the environments on the repository:
    gh api repos/<OWNER>/<REPO>/environments

    # list secrets for that environment:
    gh api repos/<OWNER>/<REPO>/environments/<ENVIRONMENT>/secrets

Output of the CLI calls:

From then you get options to set (create), delete or update the value of the secret. Retrieving the value of the secret is not possible, since there are no API calls for that, which makes sense since they are secrets.

Examples of setting a variable:

# Paste secret value for the current repository in an interactive prompt
$ gh secret set MYSECRET

# Read secret value from an environment variable
$ gh secret set MYSECRET --body "$ENV_VALUE"

# Read secret value from a file
$ gh secret set MYSECRET < myfile.txt

Figuring out environments and secrets

The environment secrets can be listed by users with write access, and they can create environments directly with the API.

For creating an environment you need to have write access to an repo, and the repo needs to be in an Organization. User space repos do not work with this write API.

    # list secrets for that environment:
    gh api repos/<OWNER>/<REPO>/environments/<ENVIRONMENT>/secrets

For creating environments in your own user space, you have Admin access so you can use this API call. If you add a body you can the timeout rule, specify protection rules (who needs to approve the job that targets the environment) as well as the deployment branch rule (which branch is allowed to target that environment).

 gh api -X PUT /repos/<OWNER>/<REPO>/environments/NEW_ENVIRONMENT

Results:

If you are invited as a Collaborator to another user’s repo, you cannot create environments with the API. Trying to make the call you can get two results:

404: Not found (repo is private)
403: Forbidden (public repo, but you do not have admin access)

As long as you do have read access to the repo, you can list the environments:

    # list the environments on the repository:
    gh api repos/<OWNER>/<REPO>/environments

💡 As you have read access to all public repos, you can list the environments on any public repo as well. Since this information is already available from the workflow files (and they are public), having the name of the environment is not a big deal. Unfortunately the API returns all there is to know about that environment, including the deployment branch and protection rules. The feedback I got from GitHub is that this is ‘by design’. You can get similar information from the branches API.

Closing thoughts:

The only thing that is not available this way is retrieving a list of Organization level secrets: the API calls for that need admin:org scope, which a user with write access to the repository does not have by default. That is still a big missing feature, since these kinds of secrets are often used to set some large scope (often read-only) secrets for the entire organization, or to have 1 ‘team’ secret that gets added to the repos that team owns.

So, to list all the Repo secrets you can run:

gh secret list

And for finding the Environments and their secrets:

    # list the environments on the repository:
    gh api repos/<OWNER>/<REPO>/environments

    # list secrets for that environment:
    gh api repos/<OWNER>/<REPO>/environments/<ENVIRONMENT>/secrets

DEV Community: Rob Bos

Best Blogposts 2023

Blogposts from this year 📝

Website stats 📈

Dependabot alerts triaging in GitHub

Only show alerts where your code is using the vulnerable calls of the dependency

Filter on Dependabot auto dismissal

Filter on only runtime dependencies

Filter on vulnerable dependencies where a patch is available

Get alerts from GitHub Advanced Security for Azure DevOps

Loading the alerts from the API’s

Cleaning up files changed by a GitHub Action that runs in a container

Photo by Aakanksha Panwar on Unsplash

Examples

Get the user to cleanup inside of the container, or add a cleanup action in their job.

Add cleanup configuration on the container level configuration in the runner

Add cleanup configuration on the runner configuration itself

Do not run the container with any persistence

Writing to the $GITHUB_STEP_SUMMARY with the core npm package

Photo by Markus Winkler on Unsplash

Working with the table output

GitHub Advanced Security for Azure DevOps

Photo by Adi Goldstein on Unsplash

What is GitHub Advanced Security?

Dependabot / Dependency scanning

Secret scanning

Code scanning

GitHub Advanced Security for Azure DevOps

How to get started with GitHub Advanced Security for Azure DevOps

Turning on Secret scanning

Using dependency scanning

Using Code Scanning

Note that in Azure DevOps you configure this on the Analyze task where as you do that in GitHub in the Init step.

Addressing the alerts

Fixing secret scanning alerts

Fixing dependency scanning alerts

Addressing code scanning alerts

Dashboarding

Summarizing

How Copilot/AI helps me in my daily work

How Copilot and AI helps me in my daily work

Image generated with Craiyon.ai using the following prompt: sketched photo with some realism of an AI generating code.

Usual flow

Step 1: Create a new Azure Function

Step 2: Create a new node.js app for user configuration

Generated code

Conclusion

Enabling CodeQL on GitHub Enterprise Server

Photo by Barn Images on Unsplash

Syncing the CodeQL bundle

Running CodeQL efficiently

Making the case for GitHub's Secret scanning

What is GitHub Secret Scanning?

Photo by Kristina Flour on Unsplash.

Analyzing the actions repositories.

Secret scanning alerts

Analyzing the results

Adding OSSF scorecard action to your repo

Scorecard action

Scoring

Setting it up

Code scanning alerts

Restrict permission for the GITHUB_TOKEN

Add security agent for GitHub hosted runner (Ubuntu only)

Pin actions to a full SHA hash

Examples for calling the GitHub GraphQL API (with ProjectsV2)

ProjectsV2 GitHub GraphQL API

Logging in

Getting the new ID’s

Working with ProjectsV2

Working with GitHub secrets without admin rights

The premise:

Photo by Markus Winkler on Unsplash

The solution:

Figuring out environments and secrets

Closing thoughts:

Note that in Azure DevOps you configure this on the `Analyze` task where as you do that in GitHub in the `Init` step.

Image generated with Craiyon.ai using the following prompt: `sketched photo with some realism of an AI generating code`.