Workshop: GitHub DevSecOps Fundamentals [SEC2745W]

[igwejk]

GitHub DevSecOps Fundamentals

• Speaker: @igwejk (Igwe Kalu), Senior Service Delivery Engineer
  Social : You can follow me on X (igwejk) / LinkedIn (igwejk)
• Speaker: @mouismail (Mohammad Ismail), Senior Solution Architect

Note

This GitHub DevSecOps fundamentals workshop will help you begin or level up your DevSecOps journey on GitHub. DevSecOps principles enable organizations to securely plan, develop, integrate, and deliver solutions; and ultimately stay competitive in business. This workshop will demonstrate how to implement DevSecOps principles, highlighting how you can use the GitHub platform to remove the complexities and complications introduced in the development process as a result of the proliferation of tools.

👀 Workshop guide and instructions.

Thank you for joining our workshop! If you have any questions or feedback regarding what was presented, please feel free to add them in the comments and we'll do our best to answer.

[zigwe]

Short link to this discussion: https://gh.io/d-u-23-feedback

[2good4hisowngood]

I'm concerned that many of us at the workshop struggled to complete it. The issues began with the prerequisites; we had additional configurations upon arrival that were not clearly communicated beforehand. This left those who hadn't completed the initial prerequisites even more confused.

The workshop's pace was excessively fast, focusing on copying and pasting rather than understanding the material. Even after passing key sections like GHAS, Administration, and Actions, the lack of clear instruction made it difficult to follow along.

It would likely be more effective to offer this content as a video series to allow participants to learn at their own pace. By rushing through the content, I missed the opportunity to absorb the information, leaving me without any meaningful insights and making the session feel unproductive. A slower, more deliberate approach would have been much more beneficial.

[2good4hisowngood]

Follow-up thought, DevSecOps is an ambitious target for a single workshop, you're taking the already complex subject of DevOps, and trying to wrap security into it, and that's an entire field. I also applaud the attempt to wrap communications in, but I think that was a distraction that didn't contribute to this already wide subject area.

Alternatively to a slower form video series, if you had the repo already set up, and spent the time explaining how best to use and modify the components like an anatomical examination of the repo, with basic levers we could pull, like kicking off a pr to make a wide variety of tests trigger and reports to be created, that would have been a lot more enlightening. It would be something I could add to my personal cookbook to whip out as a devsecops recipe to whip together, for the rest of my career (or it gets depreciated).

[igwejk]

👋 Hey @2good4hisowngood,

Thanks for following up with us! I can see where you are coming from with the thoughts you shared.

The workshop was designed for self-paced learning, and with ample notes providing guides for independently delving into concepts ondemand. Indeed, we made that design decision in anticipation of some of the points you highlighted -- specifically considering the large breadth and depth of the topic. Helpfully, this very discussion also gives us an opportunity to continue the conversation.

Moreover, we heard from another participant that they would have preferred having this particular workshop at the very beginning before others as it would have enabled them to learn with a top-down approach. I just want to say that we are paying keen attention to these feedbacks, and I will take them back to my team to help us plan even more awesome workshops.

Do you have any questions on the concepts that you would like to discuss meanwhile?

Thank you for taking your time to help us improve!

[2good4hisowngood]

I appreciate the hard work your team put into this. I couldn't have pulled it off any better. DevSecOps is a field building the entire Security field on top of the relatively novel DevOps field, and means different things to different people. When I think DevSecOps, I also look at an infrastructure aspect where the infrastructure is securely codified in terraform with all of the expectations enforced.

Suggestion - I would remove the ticket portion, as a recurring aspect it was one of the few points that forced the users to regularly make edits to the scripts being executed. I get why it was included, and it's a huge part of the GitHub platform, but it introduced potentially unnecessary complication to the instructions, especially while we were trying to do it in person. My org has made the decision to split issue/project tracking into Jira, so for my org's use case this wouldn't be as beneficial.

• Alternative middle ground solution: Have two sets of instructions like when Microsoft Learn docs have multiple language tabs you can select to get similar instructions, one including github issues (where they have to swap out the issue number), and one without where they are committing directly without issues in a known less than optimal practice.

For maximum benefit, I wish I had done the entire workshop ahead of time, so that as we went over it in person, I could validate my understanding of how it worked not just specifically, but generally. The biggest benefit I could get out of the workshop would be to leave with a roughly generalized package I could use to quickstart my own projects once back at home.

[vphan6896]

Is there a reason why we release the draft release as soon as the release assets are uploaded? I would think you would want to make that step manual.

Referring to:
https://githubuniverseworkshops.github.io/github-devsecops-fundamentals/exercises/03.automate.release/01/#__codelineno-0-83

[igwejk]

👋 Hey @vphan6896,

I believe you want to callout this sequence of steps ... --> "Draft release" --> "Upload release assets" --> "Publish release", right?

Let's zoom out to put things into perspective

stateDiagram

    workflow_create_release: Package Delivery Artifacts & Create Release
    workflow_deploy_release: Deploy Release

    step_release_draft: Draft release
    step_release_upload_asset: Upload release asset
    step_release_publish: Publish release
    step_deployment_activities: ... Deployment steps ...

    arbitrary_activity_0: ...
    arbitrary_activity_1: ...

    [*] --> arbitrary_activity_0
    arbitrary_activity_0 --> workflow_create_release

    state workflow_create_release {
      direction LR
      arbitrary_activity_1 --> step_release_draft
      step_release_draft --> step_release_upload_asset
      step_release_upload_asset --> step_release_publish
    }

    workflow_create_release --> workflow_deploy_release: trigger deployment

    state workflow_deploy_release {
        direction LR
        step_deployment_activities
    }

    workflow_deploy_release --> [*]

Loading

Important

The Publish release step ultimately triggers the deployment workflow.

So, it is necessary to begin the release creation in draft mode, allowing us to make modifications such as adding assets to it.

Warning

Here's what would happen if we bypassed starting in a draft mode but directly published the release:

1. Deployment would get triggered prematurely
2. Subsequently, the deployment run will not find any asset to be deployed ¯_(ツ)_/¯