Desktop Application

To update an existing Desktop Application, review the Software Developer Requirements page for applicable DevOps, Usability, Corporate and Security requirements. Follow the process steps below:

Note: Follow the Desktop process for Server/Enterprise, Software Extension, and Software Implemented via a Commercial Software Platform deliverables.

1. Development: Software Developer codes the application (must meet all applicable requirements provided in the Software Developer Requirements page and SQA Testing Checklist). IF an ADO Repo does not exist for the prior version release, submit the ADO Repo Request (Jira Portal Ticket #1). The source-code for your Desktop Application must be regularly checked into EPRI's On-Prem Azure DevOps (ADO) version control system. When checking in source code to ADO there a few things to be aware of:
   1. The source code must be checked into the repository created and managed by SQA - this is the official repository.
   2. Repositories are for plaintext source code - checking in build artifacts and/or large binary files (e.g. DLL, EXE, etc.) is highly discouraged unless it is absolutely needed.
      1. If your application requires third-party dependencies those will be restored via your package manager (e.g. Nuget for .NET, NPM for JavaScript frameworks, Pip for Python, etc.).
      2. Storing large non-plaintext files in these repositories will increase the time it takes to clone and pull from them and is generally bad for version control best practices.
      3. When it's necessary to store large binary files (anything above 10 MB) Git LFS should be used.
2. Security Scans and InfoSec Approval: The Software Developer must submit an ADO Repo Request and ADO Pipeline Request so that source code will be stored in the repository and Static Application Security Testing (SAST) scans can be automated in the pipeline. All Desktop applications must be scanned by the SAST solution (Checkmarx is in use at EPRI). InfoSec must approve SAST scan results prior to SQA Submittal. Checkmarx generates a report detailing the vulnerabilities found ranging from Level 1 (Low) to Level 5 (High). The Software Developer must remediate any Level 3+ vulnerabilities found during the scan. InfoSec may also require that certain lower-level vulnerabilities be fixed at their discretion. 
   1. Scan Process:
      1. The SAST scan is run automatically when code is checked into the ADO repository, or the developer may run a manual scan of their source code in the Checkmarx platform.
      2. If new to the scan process, submit the Static Application Security Scan Onboarding Request (Jira Portal Ticket #2) for system access.
      3. Scan and perform remediation, if required.
      4. InfoSec's approval on a SAST Scan Approval ticket is a required prerequisite for the SQA testing submittal.
   2. To address the vulnerabilities:
      1. Scan, remediate vulnerabilities (if applicable), and rescan. When no vulnerabilities remain, request InfoSec approval via a Static Application Security Scan Approval Request (Jira Portal Ticket#3).                
      2. False Positives: Submit evidence in a SAST Scan Approval ticket that the vulnerability is a false positive and InfoSec will review the submission. Evidence can include screenshots or code snippets. InfoSec will review the evidence for each represented vulnerability type in question. Please use the same input values that the scanner used, where applicable.
      3. If the findings are not false positives and will not be addressed by the developer, send a remediation plan (see Remediation Plan Template) to InfoSec for approval within the SAST Scan Approval ticket. Please note this should only be completed after exhausting steps 1 and 2. The risks identified and plan within the document will need to be approved by project owner (accepting the risk) and IT stakeholders (TBD on case-by-case basis).
3. SQA Submittal & Usability Testing: Project Manager submits the SQA Submittal – Software Acceptance Form (SAF) (Jira Portal Ticket #4) to submit the Desktop Application for SQA Pre-Production (Beta) or Production(Final Acceptance) Testing. Prior to submittal, the Project Manager and/or Software Developer validates the application meets EPRI requirements (see Software Developer Requirements page).

4. Distribution: Once the application receives all required approvals (e.g., Usability, Security Scans, etc.), the SQA team will release the Desktop Application on EPRI.com, making it available for download to members and/or the public.