chore(bootcamp): Prepare for Heureka Bootcamp

[lolaapenna]

Estimated Agenda

Pre-BootCamp preparations

• Friday 2nd August - Heureka Introduction with Victor and possibly the Accenture devs
• - Environment Setup
• - Ticket assignments
• - Book meeting room 12th - 18th in the office
• Establish UI workload - US, use cases, general overview - defined backlog for UI
• Define affected User Stories.

---

Potential Workload

• epic(scanner): Implement Heureka Image Registry Scanner #5
• epic(scanner): Implement Heureka Kubernetes Container Scanner #6
• epic(scanner): Implement Heureka NVD Advisory Scanner #11
• epic(authN): Implement Authentication #7
• epic(ghplugin): Implement Heureka Greenhouse Plugin #9
• epic:(filter): Implement Filter Queries for Heureka Objects #51
• epic(ui): Heureka Component Views #96
• epic(demo): Heureka Use case Demo #34

---

Workstreams

The workload is distributed across 3 work streams:

• UI
• GH Enablement
• Scanners

---

Participants

1. Michael
2. David
3. Victor
4. Lola
5. Hoda
6. Dimitris
7. Arno
8. Tilman ?

[lolaapenna]

• Meeting room C06.15 has been booked. Exploring other possibilities that allow easy access to areas with monitors.

[lolaapenna]

@MR2011 and @drochow WTYT about this Tentative Boot-Camp Agenda

Day 1: Kick-off and Project Overview

• 09:00 - 10:00: Welcome and Introduction
• 10:00 - 11:00: Overview of the Product and Goals for the Week
• 11:00 - 12:00: Ice Breaker Activity
• 12:00 - 13:00: Lunch Break
• 13:00 - 17:00: Task Planning and Assignments

Day 2: Diving into Development

• 09:00 - 10:00: Recap of Day 1 and Goals for Day 2
• 10:00 - 12:00: Frontend and Backend Development Sessions: Working on Epics
• 12:00 - 13:00: Lunch Break
• 13:00 - 16:00: Continued Development Sessions: Working on MVP Epics
• 16:00 - 17:00: EOD review

Day 3: Mid-Week Check-In and Continued Development

• 09:00 - 10:00: Recap of Day 2 and Goals for Day 3
• 10:00 - 12:00: Frontend and Backend Development Sessions: Working on Epics
• 12:00 - 13:00: Lunch Break
• 13:00 - 14:00: Mid-Week Check-In: Progress Reports and Adjustments
• 14:00 - 16:00: Continued Development Sessions
• 16:00 - 17:00: EOD review

Day 4: Final Development and Initial Testing

• 09:00 - 10:00: Recap of Day 3 and Goals for Day 4
• 10:00 - 12:00: Frontend and Backend Development Sessions: Finalizing Epics
• 12:00 - 13:00: Lunch Break
• 13:00 - 16:00: Initial Testing and Bug Fixing.
• 16:00 - 17:00: EOD review

Day 5: Review and Wrap-Up

• 09:00 - 10:00: Recap of Day 4 and Goals for Day 5
• 10:00 - 12:00: Final Testing and Bug Fixing
• 12:00 - 13:00: Lunch Break
• 13:00 - 15:00: Review of finished Epics and Feedback Session
• 15:00 - 16:00: Wrap-Up and Next Steps for continued Product Development
• 16:00 - 17:00: Closing Celebration

[lolaapenna]

Day 1: Kick-off and Project Overview

• 10:00 - 11:00: Welcome and Introduction
• 11:00 - 12:00: Work-Stream Settings
• 12:00 - 13:00: Lunch
• 13:00 - 14:30: Frontend and Backend Development Sessions: Working on Epics
• 14:30 - 15:30: Ice Breaker Activity
• 15:30 - 17:00: Frontend and Backend Development Sessions: Working on Epics

Day 2: Diving into Development

• 09:00 - 09:30: Work-Stream Settings
• 09:30 - 10:45: Frontend and Backend Development Sessions: Working on Epics
• 10:45 - 11:00: Break
• 11:00 - 12:00: Frontend and Backend Development Sessions: Working on Epics
• 12:00 - 13:00: Lunch
• 13:00 - 14:00: Technical Design Discussion
• 14:00 - 15:00: Ice Breaker
• 15:00 - 16:00: Frontend and Backend Development Sessions: Working on Epics
• 16:00 - 17:00: Recap

Day 3: Continued Development

• 09:00 - 09:30: Work-Stream Settings
• 09:30 - 10:45: Frontend and Backend Development Sessions: Working on Epics
• 10:45 - 11:00: Break
• 11:00 - 12:00: Frontend and Backend Development Sessions: Working on Epics
• 12:00 - 13:00: Lunch
• 13:00 - 15:00: Technical Design Discussion
• 15:00 - 16:00: Ice Breaker
• 16:00 - 17:00: Frontend and Backend Development Sessions: Working on Epics

Day 4: Final Development and Initial Testing

• 09:00 - 09:30: Work-Stream Settings
• 09:30 - 10:45: Frontend and Backend Development Sessions: Working on Epics
• 10:45 - 11:00: Break
• 11:00 - 12:00: Frontend and Backend Development Sessions: Working on Epics
• 12:00 - 13:00: Lunch
• 13:00 - 14:00: Technical Design Discussion
• 14:00 - 15:00: Ice Breaker
• 15:00 - 17:00: Frontend and Backend Development Sessions: Working on Epics

Day 5: Review and Wrap-Up

• 09:00 - 10:45: Technical Design Discussion
• 10:45 - 11:00: Break
• 11:00 - 12:00: Frontend and Backend Development Sessions: Working on Epics
• 12:00 - 13:00: Lunch
• 13:00 - 14:00: Week Recap
• 14:00 - 15:00: Week 2 Setup - Virtual Boot-camp

[lolaapenna]

Catering request has been submitted.

[lolaapenna]

Pictorial Agenda

[lolaapenna]

MVP:

Views -
IssueMatch List
Service List
Service detail
Component list

[lolaapenna]

Boot-Camp User Stories

US ID	US Details	US Summary
A01	As an Auditor, I want to see who did which action and when to verify that the Vulnerability and Patch management process is followed according to company policies and that the platform is functioning as expected.	Logging: immutable - discovery, auth, state-change where? in App or Shipping tool?
AC 1	Every state-changing action is logged into an immutable log collection, including: - What action was performed - Who performed the action - When was the action performed - Why was the action performed
AC 2	Every authentication to the platform is logged into an immutable log collection, including: - Who logged in - When was the logon
AC 3	Every component/vulnerability discovery is logged into an immutable log collection, including: - Which tool did report the vulnerability - What got discovered (all stored details) - When was the report submitted
ASO01	As an Auditor or Service owner, I want to be able to list all in-scope vulnerability disclosures (Vulnerability Disclosure List View) by filtering, showing the number of affected components, the number of affected activities, the earliest not yet met remediation target timeline, the earliest vulnerability match discovery date, and highest severity rating to be able to validate the functioning of Converged Clouds Vulnerability & Patch Management.	Vulnerability Disclosure List Views/Pages. - Listing, filtering, and sorting capabilities of VDs' Read for VD, VM,
AC 1	Assuming I am on the Vulnerability Disclosure List view, I can filter / sort by: - vulnerability disclosure - service - vulnerability match discovery date - the vulnerability match remediation target date
AC 2	Assuming I am on the Vulnerability Disclosure List view, I only see relevant Vulnerability Matches, which are: - vulnerability matches that are not manually marked as irrelevant with a reasoning - vulnerability matches that are currently present in Production components
AC 3	Assuming I am on the Vulnerability Disclosure List view, I can select to display previously relevant (but not relevant anymore) vulnerability matches
AC 4	Assuming I am on the Vulnerability Disclosure List view, I can click vulnerability disclosure to navigate to the vulnerability disclosure detail view (ASO02) - I can select to display previously relevant (but not relevant anymore) vulnerabilities
ASO02	As an Auditor or Service Owner, I want to be able to view the details of a vulnerability disclosure (Vulnerability disclosure Detail View) and list down the affected components, including their severity rating, discovery date, and remediation target timeline, grouped by services & affected activities, including the current activity status to be able to validate the patch status of individual vulnerability disclosures.	VD detail views/pages - details should pull all associations (matches) Read for VD,
AC 1	Assuming I am on the Vulnerability disclosure detail view, I can see: - all related activities grouped by the owning service - all affected components grouped by the affected activities - all affected components that are not acknowledged through a created activity - a section, which is treated like a service named “Unassigned,” which includes all Components that are not assigned to any service. - I can see the creation date for each activity
AC 2	Assuming I am on the Vulnerability disclosure detail view, I can see for each component: - the individual severity rating - the individual vulnerability match discovery date - the individual remediation target date - the individual “remediation date”, “acceptance date”, and “in progress” depending on the status of the individual vulnerability match
SO01	As a Service Owner, I want to have an overview of my services (Service Owner Dashboard) and be able to assign components to my Service to maintain them and have an overview of my Services and the required Patch Management activities related to them.	Services List views/pages - Listing, filtering, and sorting capabilities of Services' Service detail view - details should pull all associations (matches) Read for Service, VM
AC 1	Assuming I am on the Service Owner Dashboard, I can: - See all my Services - navigate to the service detail views by clicking the - show the number of all vulnerability matches (divided by severity) - show the number of all activities
SO02	As a Service Owner, I want to have an overview of my service components (Service Owner Dashboard) and be able to assign components to my Service to maintain them and have an overview of my Services and the required Patch Management activities related to them.	Component instances List views/pages - Listing, filtering, and sorting capabilities of Services' Component Instance detail view - details should pull all associations (matches)
AC 1	Assuming I am on the Service Owner Dashboard, I can: - see all components & component versions assigned to my service - see all activities that are not finished for my service including a state - see all vulnerability matches for my service(s) that are not covered by an activity - Assign components to my service with a Filterable/Searchable select form
SOSGE04	As a Support Group Engineer, I want components, component versions, and component instances to automatically be attached to my service if they are labeled with “service:(ServiceName)” for any supported scanner.	Labels to componentInstance componentInstance-to-service match
AC 1	In the case of not matchable entries the label is ignored - only labels starting with “service:” are evaluated and Everything After is evaluated as the Service Name.

[lolaapenna]

Mural Board

[lolaapenna]

Day 1:
Expectations

• A working POC
• UI with real findings
• Search for affected components by CVE
• POC workflow - a few data from each source - basic end-to-end workflow in a UI.
• Consider useful info to show on the UI for each entity - we need to clarify what useful data is for each component and also for each persona - TDD (Personas doc)
• persona data - understand what kind of data to deliver
• set straight what GH can and cannot do
• Enable heuraka as a plugin in GH
• Persona useful info -
• DOOP - being hybrid plugin - clarify future of DOOP
• Properly represent Heureka to all stakeholders
• Foundation loose ends tied together - understand how ot all works - build a workflow.
• Establish a foundation for building plugins/services
• Narwahl personas - managers, LOBs,
• Persona use case expected data/info - LO-FI mock ups may help
• Establish user-stories and acceptance criterias to be fulfilled - identify base ACs'
• Core Features definition - map to new personas - list of features
• HAve something to deliver for now.

Core
Plugin
Real data.