In the coming months, the Nexus Lifecycle team will be implementing a new page in IQ Server, providing details on a particular policy violation. This page will be accessed from the dashboard by clicking on a result in the violations tab.
What is it?
The first iteration of the Violations Detail page will show metadata on the selected policy violation such as the coordinates of the violation, its threat level and type, when it was first and last reported, which stages it occurs in, and where its policy is defined. The page will also display the violated policy’s constraints and conditions, and indicate exactly which conditions have been violated.
Why add this content to IQ Server?
The Violations Detail page is part of a larger Information Architecture and workflow plan which we refer to internally as research and remediate. Currently the IQ Server dashboard allows for filtering your Lifecycle data into a set of violations, applications, or components. We plan to provide detail views for each of these elements, to allow closer examination. Here’s the workflow:
- Start with a question, like “which of my applications has the most severe security violations?”
- Use the dashboard filters to answer your question, perhaps modifying it to include secondary questions along the way, winnowing down to a set of elements that you would like to work with or learn more about.
- Optionally save your filter so that you can continue to work with the set of elements that interest you as your project grows and your Lifecycle data evolves. Next time, you can load your saved filter and skip steps 1 and 2.
- Drill down into the detail view of the item in your results set you’re most interested in. Your result set will follow you to the new context, so that you don’t have to pogo-stick back to the dashboard. You can march down your list, reviewing details of each element.
- Take the appropriate action for each element.
You’ll notice that #5 isn’t covered in the initial planned iteration of the violation details page. This is the remediate part, and it will be added as part of our incremental development and customer feedback process. This is why we’re starting with a violation detail page – it offers the best context to remediate policy violations.
We believe that the application report is fundamentally the wrong context for remediating policy violations. The report represents the results of a specific Lifecycle evaluation – a snapshot in time. While it’s useful to be able to access these snapshots, remediation is better performed in the context of an aggregate of the most current evaluations, which can be configured to reflect your priorities.
Our aim is to create a rich data ecosystem that is powerful enough to answer whatever questions you have about policy violations and component usage in your development pipeline, and to create remediation workflows that make sense for you.
What does your ideal research and remediation workflow look like?
As mentioned, the violation detail page is just the first step in building the planned research and remediate concept. We want your feedback as we continue to refine and implement this concept. Maybe you’ve reviewed this blog post and feel we’re going down the wrong path, or maybe you want to ensure that we’re considering your use cases. Help us provide the best possible tool by signing up to participate in our user research and feedback sessions, or respond directly to this post by dropping us a line at UX-team@sonatype.com.
