Additional Responsibilities

FlexLine is a tool for performing security accessibility scans on applications. It is currently available in the Sandbox and Staging environments for use by everyone with ActiveDirectory credentials.

POs are responsible for monitoring and resolving any Flexline findings for their components. POs monitor their widget on their project’s Flexline Findings dashboard and any Flexline finding stories for their components that are created. The PO triages the Flexline finding ticket and adds a story to fix it in their backlog, if valid. See the Flexline Finding Process for more details on what flexline findings are and how they are resolved.

POs should have a general understanding of how their component(s) are doing and what’s going on with them. Routinely check the tools (grafana, k8s dashboard, kibana, etc) and know to better understand the ins and outs of your component(s).

Monitor services in SQA/Prod to proactively identify and resolve issues / bugs. Work closely with SREs when problems arise, be involved with filing any bugs, and prioritize them correctly in the backlog with your PM.

Similar to Flexling Findings, POs are responsible for monitoring and resolving any OIS findings for their components. Twice weekly OIS scans the latest release/* branch. If there is a finding, it will be automatically created as a story in the Jira project space (Type: Flexline Finding, Component: service they scanned and found issue with). Each scan will include one to three labels, depending on the scan that occurred: CodeQL, DependBot, SecretScan. OIS tickets will automatically close out after a new version of the service is released, OIS scans the new version, and clears the vulnerability.

A major limitation of OIS Scans we get from GitHub is we can only scan one branch. So we are scanning the latest release branch of the latest major version only (authoritatively, we can do info only "preview mode" scans on other branches). As a policy, we only should have OIS Scanning added to repos that do go to production.

Work with your team’s PM to establish the role the PO plays in preparing and executing PI Planning/PMR. Potential duties include prioritization of Milestones, story writing, and sprint planning.

Sonar is part of the Jenkins pipeline, in the sandbox environment this runs with a preconfigured set of rules against the branch that is being scanned. Sonar runs in the staging environment as well, but it has become rare to have an issue in staging if the sandbox build succeeded. The most common reason for a build to fail is because the code coverage for new code is below 80%. There can be other security, maintainability, or reliability issues that can fail a build. It is recommended to try to bring code coverage on each component as close to 100% as possible so that any new code can easily be tested and covered. SonarQube is a good source for technical debt to add to the backlog for a component.

Prepare and explain content within stories that will be worked in the upcoming sprint. PO’s are component resources to the devs throughout the sprint where discoveries within the story may need further clarification.

Give updates during sprint retrospective on work that was completed during the previous sprint for all their components.

A Software Service Design Document (SRVDD) is a technical document that describes how a software product will be built to meet the needs of the client. A SRVDD has to be resubmitted for any architectural changes, including adding or removing endpoints. A new review is required for all major versions. The average time from submission to approval is 1-2 months. Approvals are required before going to production (approved or approved with constraints), but services can have several SRVDDs in the approval process at one time. You should provide your SRVDD link to your PM to submit as soon as possible.

Participate in troubleshooting exercises with both internal and VA personnel to provide solutions to any component related issues.

VAMFAT reviews are triggered when a service is first being deployed, when a new endpoint is added / changed / deleted and when a new major version is released.

Work with your PM to get the VAMFAT submitted early. They’ll need the SRVDD to start this. VAMFAT Reviews take time, a month or more, so POs should get it submitted early before major work is actually being done on the service.

POs will learn more about this process from your PM and contract leads.