Team evidence

DSOMM v3 had some support for evidence, but only by editing the YAML file directly.

In v4 we should make a way to:
A) display evidence
B) allow inputting evidence

Evidence is text written to "prove" that an activity has been done. An example from an earlier release:

 teamsEvidence:
   B: All team members completed OWASP Secure Coding Dojo training on 2025-01-11. 
   C: |
     The pentest report from 2025 has been split into Jira tasks under
     [TODO-123](https://jira.example.com/issues/TODO-123).
     
     _2025-04-01:_ All fixes of **critical** findings are deployed to production.

Some organisation require this. Some don't. Some require the evidence to be updated at defined intervals during the year.

Technically, one can view the evidence as a comment field. But an important one. One that has organisational value.

Evidence has a date, and often a responsible person.
I think that the same evidence text may apply to multiple teams for the same activity. It should be possible to mark which teams are appliable for the comment.

On should normally not change evidence, once it has been approved. (But this is a frontend application that stores some data ion the browser. There is no way we can implement a strict no-change policy.) But we can avoid encourage modifications. : )

@vbakke

Hey @vbakke. Here's an approach to this

Adding Evidences

An "Add Evidence" button can be added near the progress sliders. This will open a modal for adding an evidence. This will have two fields (responsible person and mardown, date can be automatically saved).

The Activity interface from activity-store.ts file can be modified to change the evidence key from a Markdown to an another interface called Evidence.

export interface Evidence {
  date: string;          // ISO date recommended
  responsible?: string;
  description: MarkdownText;     
}

The final yaml file will then be something like the eg. yaml file below

progress:
  e7598ac4-b082-4e56-b7df-e2c6b426a5e2:  # Require a PR before merging
    Team A:
      'Started': 2026-02-16

      'Partly implemented':
        date: 2026-02-16
        evidence:
          date: 2026-02-17
          responsible: "Bob"
          description: |
            The pentest report from 2025 has been split into Jira tasks under
            [TODO-123](https://jira.example.com/issues/TODO-123).

      'Fully implemented':
        date: 2026-02-16
        evidence:
          date: 2026-02-20
          responsible: "Charlie"
          markdown: |
             All team members completed OWASP Secure Coding Dojo training on 2025-01-11.

Viewing Evidences in the UI

In activity-description.component.html, there's already a "Teams Evidence" expansion panel, but it's wrapped in comments for now. We can display the evidences here.

Regarding different Organisations settings:

Types of Orgs can be configured in the settings page (preferabbly).

For orgs who require it, there will not be any button and the modal will open after adjusting the slider. As right now a star (has been modified) already comes after the slider is moved in the UI, there already is a way of knowing if the configuration is changed. Progress won't be saved if evidence is not provided.
For others, the evidence field can be optional and can be added by clicking on the button.
Special ping feature can also be implemented later for orgs that require updating quaterly/yearly.

On should normally not change evidence, once it has been approved. (But this is a frontend application that stores some data ion the browser. There is no way we can implement a strict no-change policy.) But we can avoid encourage modifications. : )

This can be done by Adding "soft immutability" — discouraging editing approved evidence (e.g., visual lock icon, confirmation dialog)

@vbakke

@vbakke
Plz Assign this issue to me.
As I am also working on the "Report" page, It'd best for me to work on this feature. I can also harmonize the "Evidence Viewing" there too.

The approach above is, of course, based on first-principles thinking and can be refined further as I work through the implementation.

I have been playing with the data structure already. I think your suggestion has some issues.

One evidence text cannot be applied to multiple teams.
Storing all evidence in the same structure in localStorage may cause rather large loads/reloads for every click on progress in the heatmap
Tying the evidence to the progress status may cause problems if someone changes the progress "downwards".
- It is quite likely that a team will get a new review, and a new "evidence text", but stays put on the progress title. (Typically Partly implemented may take some time to reach Fully implemented for some activities.

Meta.yaml

I think that evidence can be stored in the same yaml file as team progress. But if so, it should be stored under a separate "root" node:

progress:
   {activity-uuid}:
      ...
evidence:
   {activity-uuid}:
      ...

This way, evidence can easily be stored in a separate yaml file, e.g. team-evidence.yaml (as long as we add a separate entity in meta.yaml).

Local storage

When stored in localStorage, we should split evidence per activity, and separate from the rest of teamProgress (in progress), to spread the size of the blob that is written/read.

Storage key: evidence-{activity-uuid}.

Suggestion data structure

evidence:
  11111111-1111-1111-11111111111111111:
    - teams: ["Team A", "Team B"]
      title: Example Evidence 1
      evidenceRecorded: 2024-01-15
      reviewer: reviewer-123
      description: This is an example piece of evidence.
      attatchment:
        - type: document
          externalLink: https://example.com/evidence1.pdf
    - teams: ["Team C"]
      title: Example Evidence 2
      evidenceRecorded: 2024-02-15
      reviewer: reviewer-123
      description: This is a second example piece of evidence.
      attatchment:
        - type: document
          externalLink: https://example.com/evidence2.pdf
  22222222-2222-2222-2222-222222222222:
    - teams: ["Team A", "Team B"]
      title: Example Evidence 3
      evidenceRecorded: 2024-02-15
      reviewer: reviewer-123
      description: This is evidence for another activity
      attatchment:
        - type: document
          externalLink: https://example.com/evidence2.pdf

@vbakke

Sure! your approach makes more sense. Separating the progress blob from the evidence blob is a much better design.
I will start working on it shortly

I hadn’t considered this point earlier.

Tying the evidence to the progress status may cause problems if someone changes the progress downward.

Adding to that, enforcing Evidence on every progress update is also not reliable since this is a frontend application and localStorage can anyways be modified afterwards.

For organizations that require Evidence consistently, we could prompt the user with a UI modal after detecting a progress change upwards OR a dedicated button could also work — whichever fits better with the UX.

@vbakke — how would you suggest prompting users to add Evidence in the UI?

enforcing Evidence on every progress update is also not reliable since this is a frontend application and localStorage can anyways be modified afterwards.

Organizations that require Evidence consistently must use a server solution such as: https://sammy.codific.com/

The DSOMM app will not become a fully fledged system with backend storage, proper authentication, or workflows.

We should be better than Excel. And should make it easy for people to discover DSOMM, and getting started with using it.

But not aim to be a system that covers all organizational needs. That task is too daunting for a voluntary based OWASP team 🙂

how would you suggest prompting users to add Evidence in the UI?

Not sure. And I'm not sure if we need to solve that now. (Ref my comment about workflows.) If we open than can, we get a whole heap of worms to sort out. I think we'll leave the deadlines to the user.

We could however, indicate how often the management requires a review. And display this. But leave the alerting and responsibility for following up to the users. At least for now.

One thing we do need to account for, though, is renaming of team names.

So when renaming a team, I currently loop though the progress data and rename the tema keys there.

If someone deletes a team (say Team B). I do not delete the teams' progress. In case it was an error. If you recreate a new team with the name Team B, the data is still there.

I think we should follow the same principle for evidence.

This may leads to funny situations.

Delete Team B
Rename Team C to Team B
But trying to solve that takes more than it is worth. If user does that, they get what they input. Trouble. :)

@vbakke

@vbakke with YAML-files as a base for dsomm you do have kind of server side application!

@vbakke with YAML-files as a base for dsomm you do have kind of server side application!

True. But only kind of. :)
We have server side storage. But no authorization, and no workflow engines that can take steps in the background.
Any user can change the local browser data. But not every user can change the yaml data on the server. That is a valid argument.

My main point was supposed to be:
Let's not over complicate the Evidence part. This issue was an enormous potential for scope creep. So let's keep focused on the basic foundation first.

@vbakke

Hi @vbakke in this above PR, I added a data Model for Evidence in a new EvidenceStore.ts file. Please let me know if this aligns with your expectations.

Not included Yet (follow-up PRs)

UI for adding/viewing evidence
Report page integration

This issue has been automatically marked as stale because it has not had recent activity. 📆 It will be closed automatically in one week if no further activity occurs.

Issue is not stale. It is awaiting to be merged.

Navigation Menu

Repository navigation

Team evidence #496

Adding Evidences

Viewing Evidences in the UI

Regarding different Organisations settings:

Meta.yaml

Local storage

Suggestion data structure

I hadn’t considered this point earlier.

Not included Yet (follow-up PRs)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Team evidence #496

Description

Activity

sawankshrma commented on Feb 21, 2026

Adding Evidences

Viewing Evidences in the UI

Regarding different Organisations settings:

sawankshrma commented on Feb 21, 2026

vbakke commented on Feb 22, 2026

Meta.yaml

Local storage

Suggestion data structure

sawankshrma commented on Feb 22, 2026

I hadn’t considered this point earlier.

vbakke commented on Feb 23, 2026

vbakke commented on Feb 23, 2026

wurstbrot commented on Feb 23, 2026

vbakke commented on Feb 23, 2026

sawankshrma commented on Feb 24, 2026

Not included Yet (follow-up PRs)

github-actions commented on Apr 1, 2026

vbakke commented on Apr 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions