Our previous blog post demonstrated how to create a custom GitHub integration using a small Python application. In this post, we’ll explore a no-code alternative using Zapier to achieve the same integration.
No-code platforms like Zapier are ideal if you prefer not to write or maintain code. They minimize maintenance since you don’t need to update your code when APIs change or worry about hosting code.
The goal of this integration is to link GitHub issues to Reporter findings. When a new finding is published in Reporter, a corresponding GitHub issue is automatically created. Any updates to the finding in Reporter are synced with the GitHub issue, keeping information consistent across both systems. Finally, when the issue is closed in GitHub, a retest inquiry is created for the associated finding.
Prerequisites
Before getting started, ensure you have the following:
- A running instance of Reporter
- A premium Zapier account: This is essential for:
- Multi-step Zaps
- A higher number of monthly tasks
Step 1: Configure Custom fields
Log in to Reporter as an admin user. Navigate to Settings > Custom fields. We’ll create three custom fields:
- First, create a new 'Number' field for the 'Finding' model to store the GitHub issue number. Name the field
c_github_issue, which is automatically done by setting the label to 'Github issue'. In the field permissions, ensure admin users have both read and write access.
- Next, add a 'URL' field for the 'Finding' model to store the GitHub issue URL. Name this field
c_github_issue_url. - Finally, create a 'Text' field for the 'Assessment' model to store the GitHub repository. Name this field
c_github_repo.
Step 2: Create an API token
Navigate to Settings > API tokens and create a new token. Your token should have, at minimum, the following permissions:
- Read Assessments: To access the
c_github_repofield. - Read and Write Findings: For updating findings.
- Read and Write Findings Retest Inquiries: For creating retest inquiries when an issue gets closed.
- Read and Write Webhooks: Allows Zapier to automate webhook creation.
You’ll receive an API token; store this token in a safe place.
Step 3: Set your GitHub repository
Ensure you have at least one GitHub repository set up for storing issues. Update the c_github_repo field in the relevant Reporter assessments with the repository name in the format {owner}/{repository}.
Step 4: Create a Zap for creating/updating GitHub issues when a Reporter finding is updated
The first Zap will be responsible for creating or updating GitHub issues when a finding in Reporter gets updated, and linking the github issues to the Reporter findings.
Trigger setup
Begin by creating a new Zap. Select Security Reporter as the app and choose Finding Updated as the trigger event. This uses webhooks for instantaneous updates.
App search:
Finding Updated event selection:
Connect your Reporter account to Zapier using the API token and base URL (e.g., https://reporter.example.com).
During the configuration, ensure the Include field includes assessment:
Test the setup. If successful, you should retrieve some findings from Reporter. Ensure that the assessment data is included, and select a finding that has the assessment c github repo field populated.
Next add a filter step to filter out non-published findings.
Configure the filter so that is only continues if the review status of the finding matches 2 (Published).
Test this step. The following message will appear if the rule is correctly applied:
Adding paths
Create a Paths step to handle two scenarios: findings not linked to a GitHub issue and findings already linked.
Path A: Creating a new GitHub issue
Configure the path to trigger when the c_github_issue field is empty.
Test this step. The following message will appear if the rule is correctly applied:
If you see the following message instead, ensure that your rules are correct, and that the selected finding does not have any data under the c_github_issue field.
Add a step under Path A to create a GitHub issue. Select GitHub as the app.
Choose Create Issue as the action, and connect your GitHub account. Use dynamic values from the c_github_repo field to configure the repository.
Test this step to confirm that an issue is successfully created in GitHub.
Finally, link the issue back to the finding. Add another step, select Security Reporter as the app, and choose Update a Finding. Update the c_github_issue_url and c_github_issue fields with the issue’s URL and number.
After testing, you should be able to see the issue url and issue number in the data out.
At this point, it is highly recommended to return to the Test Tab of the first step (Finding Updated) and click Find New Records. Select the latest record of the previously selected finding from the provided records. This will usually be the newest record unless other findings were updated in the interim. Verify that the selected record now includes data for both c_github_issue and c_github_url.
Path B: Updating an existing GitHub issue
Configure this path to trigger when the c_github_issue field is populated.
If you followed the previous recommendation, you should see the following message after testing.
Add a step in Path B with GitHub as the app, and Update Issue under Action event. The Configuration should be the same as the Create Issue step, but with c_github_issue in the Issue field.
Test this path to confirm it updates the existing GitHub issue correctly.
Publish Zap
After completing both paths, your Zap is finished, and you can click Publish. Your Zap should resemble the following.
Step 5: Create a Zap to request a retest in Reporter when an issue closes
Create a Zap to handle scenarios where GitHub issues from your repository are closed. We will go through each step of creating this zap, however, you can also use this template for this Zap (https://zapier.com/app/editor/template/255590336). All you have to do next is fill in any missing attributes, and test that the zap works.
Set GitHub as the app and select New Repo Event as the trigger. Note that since this trigger is not using a webhook, it will not be instant.
Under Configure, select a repository, and click Yes under Issue only. We advise starting with the repository that was used when creating the Zap from Step 3 of this blog.
Before testing, we recommend closing the issue that was created during Step 3 of this blog. Then, after testing, one of the retrieved events should be the event created after closing the issue.
Next, add a filter step to ensure the Zap processes only closed issues.
If you adhered to our previous recommendations, you should see this message after testing.
If you did not follow the previous advice, it is likely that you will see a different message. We highly advise that you follow our suggestions, particularly for the first time you make this Zap, but you can still complete the Zap by clicking Skip test.
For the next step, select Security Reporter for the App, and Finding Search for the action event. For the configuration, you should have the following filter field:
After testing, you should retrieve the same finding that was used in step 3 of this blog.
For the last step, again, select Security Reporter for the App, and Create a Finding Retest Inquiry for the action event.
Under configuration, you should set the Id to the Id from the previous step. You will also need to provide a body for the retest inquiry. Here, you can link back to the GitHub issue and the user that closed the issue.
Test this step. You should be able to see that a new retest inquiry was created for the the finding.
Your Zap is now ready and should look like this:
Before publishing, we suggest including the name of the repository in the name of the Zap.
Step 6: Try it out!
To test the setup, go to a finding in Reporter and update its description. Ensure the finding belongs to an assessment with a linked GitHub repository. If everything is set up correctly, an issue will be created in your GitHub repository, and a link to this GitHub issue will appear in the corresponding finding in Reporter. Closing the issue in GitHub will automatically create a new retest inquiry for the finding in Reporter.
The finding in Reporter: 
The issue in GitHub: 
Next, close the issue, and a retest will be requested in Reporter: 