Read part 1 first over here.
Last week I learned that there are people in tech who don't know what a CVE is. This shocked me to my core! I'm not talking about people not knowing the acronym, because there are too many of those, I'm talking about not realizing CVEs are vulnerabilities.
Starting my career in a large Enterprise IT organization, I lived through two significant pushes - code scanning and accessibility.
Code scanning was a response to "upskilling" the organization in security-minded coding practices and with it came awareness of vulnerabilities.
And shortly after that came anxiety.
Anxiety that you left your source code vulnerable or that you chose a library that was vulnerable.
Maybe that's why I'm not an enterprise developer anymore...
Anyway, I finished my CVE tracker. My vulnerability tracker, if you will. I even made you a video! Just like I promised!
I was able to use both the Notion page and database plugins, including passing the right data type to use a checkbox. Huge shoutout to the plugin team, they rock!
I want to call out a few places you need to pay attention to with the Notion plugins.
Use plugin defaults
If you plan to do multiple tasks with the Notion plugins, particularly multiple tasks with the Notion database plugin, for example, you'll need to reuse some information, like the databaseId.
I like to think I future-proofed this a bit because I only did 3 tasks across the two plugins. Still looks cleaner when you read the entire workflow.
pluginDefaults:
- type: io.kestra.plugin.notion
values:
apiToken: "{{ secret('NOTION_SECRET') }}"
databaseId: "{{ secret('NOTION_CVE_DB') }}"
Passing content back to Notion is a little unintuitive
I ended up having the Notion API docs open because some of the database types took me by surprise.
For example, a database can have a rich text field. In reality, I really just wanted this to be a string. Sometimes it's super simple like the CVE ID string, other times it's the action plan. So figuring out what I need to pass back to the API via the plugin was a bit awkward at first, because who would guess the rich text field would want an array of objects...? Not me.
Other types are much more straightforward like the select (priority) and the checkbox (mitigate now).
#sorry for the weird indents...
- id: send_to_notion
type: io.kestra.plugin.notion.database.CreateItem
title: "{{ json(parent.taskrun.value).vulnerabilityName }}"
properties:
ID:
rich_text: [
{
text:
{
content: "{{ json(parent.taskrun.value).cveID }}"
}
}
]
Priority:
select:
name: "{{ outputs.ask_ai[parent.taskrun.value].predictions | first | jq('.priority') | first }}"
"Mitigate now?":
checkbox: "{{ outputs.ask_ai[parent.taskrun.value].predictions | first | jq('.mitigate_now') | first }}"
"Action plan":
rich_text: [
{
text:
{
content: "{{ outputs.ask_ai[parent.taskrun.value].predictions | first | jq('.action_plan') | first }}"
}
}
]
Added an SLA
In kind of the perfect storm of situations, I did a webinar last week where we talked about "hidden" features, one of them being the workflow SLA. I ended up adding one:
sla:
- id: maxDuration
type: MAX_DURATION
duration: PT1H
behavior: CANCEL #CANCEL, FAIL, NONE
labels:
sla: miss
reason: durationExceeded
This particular SLA will cancel the execution when it runs for over an hour. I actually exceeded this before my webinar without trying, which was cool because I had a nice example to share.
Notice I left a comment in the behavior property - you can set the behavior to cancel, fail, or do nothing (none).
Wrapping up
So that completes this little demo. I mention this in the video, but internally at Kestra we use Notion for our knowledge base, so the idea of having a CVE Tracker table within Notion makes a lot of sense for us. We can track the associated work, assign a reviewer, and have people view the page if they are interested in the progress.
I'm curious if anyone else out there is using Notion. How are you using it? How would you automate or orchestrate something around your Notion use?
And before I truly sign off, on my last run we hit 1568 CVEs. So I could definitely look at improving the performance here with a little refactor to only look at the newest ones every pull.
