In the past couple of weeks we worked on some fundamental architectural changes to Hakiri. Those changes are going to make everyone’s lives easier.
One of the biggest user experience hurdles that some of our customers experienced were related to the confusing concepts of issues and warnings that essentially represented two different things: CVE vulnerabilities and static code analysis warnings. The problem is that warnings and issues are two fundamentally different concepts, yet we assigned both of them to each build making it seem like they were the same. This setup made it impossible to mark CVE vulnerabilities as false positives and users couldn’t reference those vulnerabilities in the context of project branches.
The solution to the problem turned out to be very simple: instead of assigning CVE issues to builds we now generate warnings for those issues. That means that the set of actions that users could perform on code warnings can now be performed on CVE warnings as well. Namely, marking issues as a false positives and having reference links in various app integrations.
Marking warnings as false positives is very useful in static code analysis, since this technique results in a lot of false positives. Many of our customers used it successfully and requested that we have the same functionality for CVE vulnerabilities, since these kinds of vulnerabilities are often patched internally without modifying the version of a vulnerable technology.
This finally became possible with the latest Hakiri update. Marking a code warning as false positive checks all builds from currently followed branches and marks all future occurrences of this warning across all branches. Marking a CVE warning as a false positive works slightly differently: it checks all builds in the current branch only and marks all future occurrences of this warning in the current branch. The difference is due to the fact that branches often represent different stacks that might or might not have local patches deployed, as opposed to code warnings where a false positive is the same across all branches.
Now you can reference each warning with a URL. This comes in handy when you are using app integrations because each warning can be linked to directly in the outgoing message.
Currently Hakiri only supports email, GitHub, and Slack integrations: you can hook up your Slack channel for warning notifications, create issues on GitHub with prefilled descriptions in one click, and receive email notifications whenever new vulnerabilities come out for your technologies.
Among other improvements I want to highlight better build messages and more meaningful UX for warning insights. The former includes labels for each build that indicate whether a build succeeded, failed, or is in progress. Failures could be due to many different reasons, so each reason has an explanation and a recommendation on how to fix it.
Minor warning UX improvements include listing all build warnings in one list and showing a number of warnings in the projects view. The latter allows you to find out which projects require attention in a glimpse instead of checking every one of them individually.
I hope you’ll find all those improvements helpful while working with Hakiri. As always, let me know if you have any comments or feedback.