[kcdc 2022] building rugged devops pipelines with github

Speaker: Brian Gorman @blgorman

Repo: https://github.com/blgorman/codemash-rugged-devops

For more, see the table of contents

DevOps

  • Process, not product
  • Can’t buy tool (but can buy an existing team)
  • Goal: reduce cycle time form idea to production with minimal error
  • Automated testing
  • Gates – automated and human, quality, release
  • Avoid 2am support calls. Or at least only have to push a button to recover

Shift left

  • Less cost if find bug early
  • Reusable processes
  • Push quality upstream
  • Dev machine is as far left as can go
  • Build scanning tools into process
  • Sell the vision

Prereq

  • Cloud env exists
  • Templates

Actions

  • .github/workflows – folder
  • Actions tab to see result

YAML

  • on: the triggers (ex: push, pull_request)
  • env: (ex: branch)
  • jobs: want you want to do
  • with: trigger another job

Infrastructure as Code

  • Declarative
  • Repeatable Results
  • Ensures no configuration drift
  • Azure has imperative and complete options for ARM templates – complete is destructive and dangerous. Anything added outside code deleted.
  • Tools – ARM templates (Bicep) , Terraform, Ansible, Puppet/Chef, Pulumi

Security

  • App registration so github actions get access to Azure and add credential
  • Setup github token

SonarCloud Scanner

  • Most popular
  • Not free
  • Can choose whether to require fixing of warnings

Dependabot

  • Brining in dependencies without knowing
  • Alerts on insecure package
  • Options for security updates

OWASP

  • Zap Scan
  • Baseline (lightweight) scan for pull requests
  • Full scan overnight
  • For penetration test, provide valid URL so can try to hit it
  • WhiteSource – GP Security Scan

Q&A

  • Azure DevOps pipelines easier if new team
  • Azure DevOps has better gating
  • GitHub getting better.

My take

The room was full. When I walked in, Brian was talking. I was worried he started early, but did not. He was just talking to the audience who arrived early separate from the session. It was a good intro to github actions. Also if it has been a while (more features now.) I’m glad the code was in a repo so I could read it on my screen. I’m sitting in the back (because my talk is right after this and I need to leave early) and can’t read the code from here. It’s also nice to have as a reference. I also like that he covered integrations like Sonar.

Github from Microsoft JDConf

Presented by: Byron Walker and Trent Jones

General note: I didn’t get much out of this . The font/resolution was too small/blurry for the demo even full screen and I had some “distractions” at my end. I’m sure it was recorded and in theory I can go back and watch it one day. The demo was fine though. I got the idea. Felt kinda commercial like. And was shorter than I expected. Listed as 25 minutes; was 15. And only half was demo. The other half felt like doc reading. Oh well. My notes:

Dependabot

  • Enable in settings: Dependabot alerts
  • Get security alerts on dependencies
  • See in email or in UI
  • Can make pull requeests

Codespaces

  • containerized
  • web based VS Code. Or connect from standalone VS code

GitHub Actions

  • Showed .yaml edited in codespace to create CI
  • Supports running tasks in parallel
  • Many OSS workflows that can reuse

GitHub Packages

  • Showed docker package from repo
  • Supports docker, npm, maven, nuget

github – one of your dependencies has a security vulnerability

Yesterday, I committed a new project to github. I wasn’t paying attention and made a (mental) typo in typing the jackson-databind version number. I typed 2.2.3 instead of 2.10.3. The former is an old version with security vulnerabilities.

This meant I got to try out a new feature I had only read about – github informing you about the security issue in a dependency. Looking at the repo, I saw a nice yellow box – “We found potential security vulnerabilities in your dependencies. Only the owner of this repository can see this message”

GitHub also created a pull request offering to “Bump jackson-databind from 2.2.3 to 2.9.10.3”. I chose not to accept the pull request and choose the later version I intended – 2.10.3.

After pushing that change, the yellow box went away. GitHub even noticed that I updated the pom.xml and closed the pull request with the message “Looks like com.fasterxml.jackson.core:jackson-databind is up-to-date now, so this is no longer needed.”.

I then went into my gmail and deleted the 18 emails with the subject “One of your dependencies has a security vulnerability.” All of these emails arrived within two hours after I committed. That’s way too many notifications!