Enable Threat Dragon as a part of CI/CD Pipelines

[ShubhamPalriwala]

While I was pondering over this at #88, I think we should definitely have a well-documented API, but along with it, also have a GitHub Action that makes the integration of Threat Dragon really easy for organisations.
Once we have this, it can stand out as a feature and will really help projects in easy integration without having to manually run it every time. Hence enhancing their DevSecOps cycle.

I discussed this with @jgadsden and we think this can be a great project for this year's Google Summer of Code too under OWASP! Once we have a more concrete plan on this, we can apply for it here too on the OWASP Project Ideas for GSOC 22 for Approval! But we need to be quick here with this.

Open to discussions over this(quite literally)!
CC: @jgadsden @lreading

[jgadsden]

This feature would certainly be good to have - and once it is in organisations CI/CD pipelines then it will be a critical feature ... as in we must not break it :)

Shubham provided this link to OWASP's involvement with GSoC:
https://github.com/OWASP/www-community/blob/master/pages/initiatives/gsoc/gsoc2022ideas.md

[lreading]

Totally agreed. This would help Threat Dragon stand out quite a bit. Another idea I've toyed with in the past is creating a Jenkins plugin as well. I'm not sure how nicely node will play with a Jenkins plugin (I've only seen them in Java), though I'm sure it can be accomplished.

GH Actions are already node, and seem relatively easy to write/publish. I'm 100% behind this. I think the hardest part is going to be figuring out exactly how the API works, structuring it well, etc. :)

[ShubhamPalriwala]

I agree with @lreading too!
The project can start with defining the API and its endpoints as you said. Once we have an API, writing a GitHub action will be easy using it. The difficult part would be to handle all the corner cases and make the API as customizable as possible for the end-user. Because organisations usually like to customise their pipelines.

So we need to ideate on the API Structuring and a basic Schema defining followed by deciding the parameters we provide to the users.
Once the API is well organised and tested, we can go ahead and create a GitHub Action and a Jenkins Plugin!

We can follow the REST Architecture so that even though the Jenkins plugin is written in Java, all we need to do is to call the API.

Adding to the clients, what are your thoughts on making this available via various package managers like npm, cargo, etc? Since we'd already have a REST API, all of this might not be that big of a hassle but will add well to our library support!

[ShubhamPalriwala]

@jgadsden Google gives us 2 duration options to choose from, one is 175 hours while the other is 350 hours.

As per my experience, I feel we can have the 175 hour option and have the Goals as:

• Architect and Document the API
• A GitHub action

The Jenkins Plugin can be an added brownie.

Open to your thoughts on defining the Goals so that we can then work further on the Mentee requirements and how one can get started! @jgadsden @lreading

[lreading]

I think the biggest hurdle is going to be defining what the API does. You brought up some great points with keeping it customizable enough to be useful to a wide range of orgs. IMHO, implementing it is going to be easier, but if we implement a not well-thought-out API structure, we could get locked into it moving forward. So - what exactly does the api do? I think to get it started, we can break down what the API does by starting with actions/entities, and then we can flesh out implementation details after. Just my $0.02!

[lreading]

Sorry, another thought:

The server is set up to use JWTs. The JWT should hold an encrypted copy of whatever auth token is provided by the backing auth (currently just github, but more in the future). This should be abstracted enough allow us to be able to start building out the API without having to worry about specific auth implementations.

[ShubhamPalriwala]

Till now, I was assuming we would just extend the current API and add these endpoints there themselves. Are you thinking of something like a new microservice that communicates with our td.server under the hood?

And regarding the auth, we'll communicate the entire auth process via our td.server itself so any change there will reflect here directly instead of writing out own for this case. This would follow the DRY principle as well as follow uniformity across the project!

[ShubhamPalriwala]

And for the features, for starters

1. One endpoint to take in the URL of the repo/branch so that we can read the source code(if needed), test actions(if needed) and get the input threat-dragon json (the location being passed as an argument and if nothing is provided, we can start with the default json)

   • The endpoint returns back a response with the analysis based on the input

2. One to auth with the service

   • This returns back an encrypted JWT for the specific user/org

[lreading]

I'm still thinking extending the current API. In its current form though, the current API is a basic CRUD operation for threat models. I'm not sure if that's the type of API everyone is looking for though, maybe it is? I may be over-thinking it. 😄

[jgadsden]

We have a few decisions to make regarding GSoC - as we are going to apply this weekend:
OWASP Threat Dragon
short description of this project
Explanation of Ideas
Some description of the task
Expected results
what we aim to achieve
Getting started
where can they get the code (an easy one) and who to discuss it with
Student Requirements
javascript? Node?
Mentors
suggest Shubham and Leo?

I have major surgery in Mid March, with some months of recuperation expected, so I am not sure how well I can be a mentor

@ShubhamPalriwala if you like we can list you as a contributor on the OWASP project page - this will show your status on the project when people are considering this idea:
https://owasp.org/www-project-threat-dragon/

[andk123]

I second @lreading as a mentor. For myself, I'll take the Mentee position as well 😄

[ShubhamPalriwala]

As far as I know, I don't think so we can have 2 Mentees for 1 project idea ideally :(

[andk123]

Ok yes @ShubhamPalriwala you're right! I just finished reading about the GSoC program more in details. Well in that case, let's go with your initial idea :) It'll take me some more time before feeling comfortable as a mentor

[ShubhamPalriwala]

Well it'd be great to have you along with Leo as Mentors so that I can learn and grow the project in a more efficient way!

[lreading]

Flattering, but I think you'll be the one taking me to school, @ShubhamPalriwala ! 😆
I spent a few minutes looking through Google's mentoring guide as well as the OWASP page on it, and I'm still not 100% clear on how the process works and what the expectations are.

With that said, if this is something you want to do and have the time for, then I'm 100% on board and will support you all the way! I'll keep reading in the interim to make sure I understand what I'm getting into. 😁

[jgadsden]

We have the timeline and ideally we need to get this done by tomorrow - this will give OWASP time to apply to Google:
https://developers.google.com/open-source/gsoc/timeline

@andk123 and @lreading if you are OK with being a mentor then this is the snippet from OWASP instructions you may need to follow:
Subscribing as mentor
To subscribe as mentor, you need to complete a few easy steps.
Contact the OWASP GSoC administrators to let them know which project you want to mentor for
Log in to Google Summer of Code Program Site
Apply as a mentor for OWASP
Subscribe to https://groups.google.com/d/forum/owasp-gsoc

Here is the proposed wording (@andk123 I do not have an email address for you so have put your github profile)

OWASP Threat Dragon

Threat Dragon is a threat modeling tool used as part of a secure development lifecycle, and is widely used by many organisations and companies to create threat model diagrams. It is an OWASP Lab project and is in the process of developing a new version using Vue and Node.

Explanation of Ideas

Of the various features that are waiting to be implemented for Threat Dragon, the one chosen for GSoC is self contained and directly visible to users of the project.

Enable Threat Dragon as a part of CI/CD Pipelines

Threat Dragon is used by many companies and organisations for their threat models. At the moment it is not easy to use Threat Dragon in a CI/CD pipeline, and it would be great if CI/CD pipeline integration was provided by Threat Dragon. This is a feature that is at the beginning of development, which allows the developer to design it from scratch and see it all the way through to acceptance by the Threat Dragon community.

Expected Results

• Decide on what functionality is suitable for a CI/CD pipeline
• Architect and Document the API
• Incrementally implement the feature as a GitHub action
• Respond to feedback from the Threat Dragon community
• If a Jenkins Plugin can be provided then that is an added brownie

Getting started

• The project is written in Javascript, so some experience in this language is needed
• There is a feature request for this work, and this will give some idea of the scope
• There are some developer notes that give a flavour of our development process

Mentors

• Arnold Kokoroko - OWASP Threat Dragon main contributor
• Leo Reading - OWASP Threat Dragon Project Leader

[lreading]

@andk123 - Were you able to apply as a mentor on the GSoC website? I logged it, it told me it couldn't find an account, and I was unable to find any way of registering.

I did request to join the mentor mailing list. :)

[andk123]

@lreading Same here. I am under the impression that we need to be invited by the mentoring organization (OWASP) admin after the project is accepted, to become a mentor of the project. Any way to confirm this @jgadsden?

[jgadsden]

There is a channel #gsoc channel on the OWASP Slack - but I could not see any specifics there
I have asked the question on it ... will see what Simon comes back with

[lreading]

@ShubhamPalriwala - I just got a reminder that the project proposal deadline for students is the 19th (less than 2 days, my apologies). If you're still interested, did you already submit the proposal?

[ShubhamPalriwala]

Yessss @lreading I'm working on the timeline of the proposal. Will ping you on Slack once I submit it for some feedback!

[jgadsden]

Cool, thanks everyone - I will add the email address and then submit the pull request

[jgadsden]

... and done: OWASP/www-community#557
I pruned the text a little bit to make it less wordy

[lreading]

Thanks for getting this done so quickly, Jon!

[ShubhamPalriwala]

Hey so quick update, I'm starting my research and understanding the following tools to see what all they've provided wrt CI/CD:

• OWASP Threat Dragon
• Poirot
• MS TMT
• SeaSponge

Let me know if yall have anything in mind.
CC: @jgadsden @lreading @andk123

[jgadsden]

Hello @ShubhamPalriwala - just checking that you have applied for this project? The application deadline is 19th April

[ShubhamPalriwala]

I will submit the proposal and let you know ASAP i do it!

[jgadsden]

Looks good @ShubhamPalriwala - you may like to look at pytm and threagile as well, but I do not think I see any CI/CD pipeline integration for these