Subscriber Website (SWS)

To develop and publish a Subscriber Website (SWS), review the Software Developer Requirements page for applicable DevOps, Usability, Corporate and Security requirements. Follow the process steps below:

Before you start the development of your Subscriber Website (SWS), determine which of the SWS hosting options works best for your deliverable: 

• Standard SWS - Follow all steps below.
• Apps (e.g., Python) - Follow all steps below.
• MediaWiki - Follow the Standard SWS process except for the Steps 3, 4, and 7. 
  • Preproduction submittals are not required for MediaWiki sites; however, is available upon request. 
  • Prior to development, review the Wiki Development Guide (Internal EPRI URL).

• Microsites – For the Microsite development process, review and complete the Web & Mobile Request Form (Internal EPRI URL) in ServiceNow. 

   

1. SQA Intake Meeting (OPTIONAL): If not sure which hosting platform to utilize, the Project Manager starts the SWS process by requesting an SQA Intake Meeting (Jira Portal Ticket #1). The meeting will help determine which hosting platform to choose or if an alternate solution is required. When the SWS hosting platform is determined, continue to the next step.
2. Obtain SWS URL and SWS Access ID Approvals:  Project Manager must obtain approvals for the URL and SWS Access ID by submitting these forms:
   1. SWS URL Approval Request (Jira Portal Request #2)
   2. SWS Access ID Request (Jira Portal Ticket #3)

3. SWS Kick-off Meeting: Project Manager completes SWS Kick-off Meeting Request (Jira Portal Ticket #4). SQA coordinates the Kickoff Meeting with the appropriate IT personnel, Project Manager, and Software Development team to review the checklist and confirm readiness to proceed with the SWS development process. In some cases, if the checklist responses sufficiently meet the criteria, SQA may approve development without holding the meeting. 

   Upon a successful kick-off meeting:

   1. Approval to start development of the SWS will be given
   2. An On-Prem Azure DevOps (ADO) repository (Jira Portal Ticket #5) will be created by SQA for the project team to:
      1. Check in source code
      2. Request pipeline development
      3. Run the Checkmarx Source Code Security Scanner
      4. Compile/deploy code to EPRI IT Servers.
   3. Standard SWS:
      1. Must be compatible on the following stacks: 
         1. Microsoft Windows Server 2016
         2. Microsoft Internet Information Server 10
         3. Microsoft SQL Server 2019
      2. Supported Programming Languages/Frameworks:
         1. Server-side languages/frameworks: .NET Core (C#, VB.NET, etc.), Python, and PHP
         2. Client-side languages: HTML, CSS, JavaScript
   4. Apps (e.g., Python) SWS: 
      1. Must be compatible with the standard development stack (3.C) with the exception:
         1. Cannot utilize database, must be self-contained. Utilization of independently published endpoints is allowed (e.g., external API or database that is maintained separately from the application).
         2. Cannot utilize PHP
4. Customer Experience (CX) Meeting: Project Manager working with the Software Developer submits the SWS Customer Experience (CX) Meeting Request (Jira Portal Ticket #6). The meeting will serve to:
   1. Align the SWS development with the overarching EPRI branding strategy
   2. Review the SWS customer/user experience
      1. Prepare a demo or mockup of the SWS to share via WebEx if possible 
      2. Review development requirements BrandEPRI (Internal EPRI URL), Web & Mobile UX v5.0, and EPRIMobileFrameworkv1.0.pdf
      3. Determine next steps for the project
5. Development: Software Developer codes the SWS (must meet all applicable requirements provided in the Software Developer Requirements page and SQA Testing Checklist). During this process you must upload your source code to the On-Prem ADO repository and request pipeline development.
   1. To Request Pipeline Development submit the ADO Pipeline Request (Jira Portal Ticket #7) uploading the source code build instructions (example provided) to develop your pipeline. The pipeline configuration is crucial to the SQA standing up of your site in the DEV, TEST, and PROD environments. SQA submittal cannot take place prior to the accessibility of your site in the TEST environment. Once the request is received an estimated completion date will be provided.
   2. The source-code for your SWS must be regularly checked in to EPRI's On-Prem ADO version control system. On-Prem ADO will serve as an IT managed backup for the code as well as a continuous integration (CI) system that will compile and deploy your code to EPRI IT managed web servers, along with the capability of running a Checkmarx source code scan in the build pipeline. 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.
   3. In Addition:
      1. If your application requires a database, please contact the DBA team with a backup file of your database so that they can restore it into an IT managed DB.
      2. You may request preliminary Qualys Web Application security scans in preparation for the next step to get ahead on remediating security vulnerabilities.
      3. Nuclear Sector SWS must include the Nuclear QMP Database Agreement Splash Screen in the application.
6. Security Scans and InfoSec Approval: All SWS at a minimum are scanned by Checkmarx and Qualys.  The Software Developer must submit an ADO Repo Request and ADO Pipline Request so that source code will be stored in the repository and Static Application Security Testing (SAST) scans can be automated in the pipeline. SWS that utilize APIs and container images must also be scanned by 42Crunch and AquaSec respectively. Each scanning tool typically 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. Security Scan Tools:
      1. 42Crunch – Scans APIs
      2. AquaSec – Scans container images
      3. Checkmarx – Static Application Security Testing (SAST) analyzes source code
      4. Qualys – Dynamic Application Security Testing (DAST) simulates external hacking attempts
   2. SAST 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 #8) 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.
   3. To address the vulnerabilities:
      1. Scan, remediate vulnerabilities (if applicable), and rescan. When no vulnerabilities remain, request InfoSec approval via Static Application Security Scan Approval Request (Jira Portal Ticket #9).
      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).
   4. DAST Scan Process: The Qualys scan is performed by SQA. After obtaining the Checkmarx scan approval, submit the Qualys Scan Request (Jira Portal Ticket #10). SQA will run the scan and provide scanning results. If remediation is required, SQA will re-run the scan and the process repeats until there are no Level 3+ vulnerabilities. False positive evidence or a remediation plan can be submitted to InfoSec within the Qualys Scan Request ticket similar to the SAST approval process.
   5. API/Container Scan Process: If APIs or containers are indicated in the SAST Onboarding ticket, InfoSec will run scans and work with the developer to remediate any scan results. 
7. Design Approval: Project Manager submits the SWS Design Approval Request (Jira Portal Ticket #11).
8. SQA Submittal & Usability Testing: Project Manager submits the SQA Submittal – Software Acceptance Form (SAF) (Jira Portal Ticket #12) to submit the SWS for SQA Pre-Production (Beta) or Production (Final Acceptance) Testing. Prior to submittal,  the Project Manager and/or Developer validates the SWS works in the EPRI TEST Environment and meets EPRI requirements (see Software Developer Requirements page). Be sure the submit the SWS Promotion Checklist information. It is required for the Promotion phase.

9. Distribution: Once the SWS has received all required approvals (e.g., Usability, Security Scans, etc.), the SQA team will schedule a Production promotion date at which time the SWS will be promoted to PROD and made externally available to members and/or the public. The SWS Promotion Checklist received with the testing submittal will determine how SQA promotes the SWS. By default, SQA will promote the code and database from TEST to PROD as is, with the only exception being necessary database connection config changes, unless otherwise specified.