This page outlines the EPRI Software Development Requirements that all software developers must adhere to. These requirements are not just guidelines; they are contractual obligations as agreed upon in the signed software development contract. Please review all sections carefully and ensure full compliance throughout your development process. Adhering to these standards helps EPRI maintain quality, security, and consistency across all EPRI developed software. Once you have reviewed and understand the EPRI Software Development Requirements, you may proceed to the Software Development Process. If you have any questions, please contact Software Quality Assurance (SQA).
All software development must be conducted within the approved EPRI development environment. This includes using designated tools, platforms, configurations, and repositories as defined by EPRI.
Conforming EPRI’s development environment ensures consistency, security, maintainability, and compatibility across all projects. Unauthorized use of external or unapproved environments may result in integration issues, security risks, or non-compliance with corporate policies.
- Contractor Onboarding: All contractors onboarded into the EPRI secure software development environment will have access to the following development tools:
- Access: Citrix
- DevOps: Azure DevOps (ADO)
- Bug Tracking: Jira
- Knowledge Base: Confluence
- Security Scanner: Checkmarx (Source code), AquaSec (Containers), 42Crunch (API)
- Source Code: All source code must be uploaded to the provided ADO repository and scanned by Checkmarx, AquaSec, and/or 42Crunch as applicable.
- Coding Standards: To review EPRI's coding standards, you can find them in the Coding Standards section of the Resources page.
All EPRI software deliverables must undergo at least two formal testing phases:
- Pre-Production (Beta) Testing – Conducted with a limited group of users to identify early issues.
- Production (Final Acceptance) Testing – Ensures the software meets all defined requirements before acceptance.
While individual project scopes may include additional testing guidance, the submission of one or more software builds alone does not constitute deliverable completion. A deliverable is only considered complete when:
- Both Pre-Production Testing and Production Testing have been successfully completed, as defined on this site, its references, and the project’s scope of work.
- The software meets all Usability, Corporate, and Security requirements. Any defects identified during testing have been resolved to the satisfaction of the project manager.
No deliverable will be accepted or noted as completed until these conditions are fully met.
The Software Quality Assurance (SQA) Testing Checklist provides the required testing items, such as Documentation, Installation, Sample Problems, and GUI & Stress Testing that must be completed for each software deliverable.
The checklist is essential for passing the SQA Usability Testing Review. SQA recommends the Development Team review the checklist to ensure their software meets the required quality and usability standards prior to SQA Submission.
The following items represent mandatory corporate software development requirements that must be met to successfully pass the SQA Usability Testing Review.
These requirements are designed to ensure that all software products meet our standards for accessibility and user experience. Please review each requirement carefully and integrate them into your development workflow. Failure to meet these standards may result in delays, rework, or rejection of the software during the review phase.
- EPRI Branding: All developed software and related documentation must conform EPRI’s official branding, please review the following: BrandEPRI (Internal EPRI URL), Web & Mobile UX v5.0, and EPRIMobileFrameworkv1.0.pdf. This includes, but is not limited to, the use of approved logos, color schemes, typography, naming conventions, and messaging tone. Adherence to branding standards ensures consistency, professionalism, and alignment with our corporate identity across all platforms and products.
- Copyright & EPRI Disclaimer: The EPRI Copyright Notice document provides templates and examples for the copyright and disclaimers required in the EPRI software, documentation (e.g., User Manual) and source code. Also included in this document is the Pre-Production Splash Screen template that must be included in all Pre-Production software deliverables.
- Software Manual Template: The software manual must conform to the EPRI Software Manual Template. The template (.dotm) contains pre-made styles and auto-text.
- Cryptography & Encryption: If software encryption (e.g., keys (i.e., hardware, software, database, etc.), data transfer, etc.) will be utilized or required in your software, work with the EPRI Project Manager to complete the Cryptography and Encryption Functions Checklist and Definitions document and submit it to the Legal Department.
- Internationalization: Internationalization involves designing software and documentation to support localization for users across different regions and languages. This includes adapting to regional settings such as units of measure, currencies, date formats, and number formats. EPRI software must support these variations, allowing users to select their preferred country settings (e.g., via Windows Regional Settings). Additionally, software manuals should clearly explain options for international units. To meet EPRI standards, all numerical data using scientific units must support both US English and Metric (SI) formats.
- Supported Systems: EPRI developed software must be compatible on:
- Operating Systems:
- If Windows:
- Windows 10 (Required in 2025)
- Windows 11 (Optional in 2025; Required in 2026)
- If Linux:
- OpenSUSE Leap 16
- SUSE Linux Enterprise Server 15 SP5
- Ubuntu 22 LTS
- If Windows:
- Web Browsers:
- Chrome (Current Release)
- Firefox (Current Release)
- Microsoft Edge (Current Release)
- Microsoft Office:
- Microsoft Office 365
- Microsoft Office 365
- Operating Systems:
- Software Licensing and Third-Party Software Compliance: All use of 3rd party software must be approved by EPRI through the Software Procurement Process (Internal EPRI URL). Developers must ensure that any third-party software, whether open source or proprietary is properly licensed to EPRI or the developer, and licensed in a way that allows EPRI to redistribute the final deliverable. If open source software is included in the deliverable, only software with permissive licenses may be used; reciprocal licenses are prohibited in EPRI deliverables. Regular communication with the EPRI Project Manager is required to confirm license compatibility. Developers are encouraged to submit third-party license terms early in the development process to avoid delays. Project Managers should consult EPRI Legal for license reviews and approvals. For development questions, work with the EPRI Project Manager. All software development must comply with:
- Software licensing terms
- Applicable sourcing agreements
- EPRI Software Policy (Internal EPRI URL)
The following mandatory corporate security software development requirements must be met to successfully pass both the Software Quality Assurance (SQA) and Information Security (InfoSec) reviews.
These requirements are designed to ensure that all software products meet our organization’s standards for secure design, implementation, and deployment. Compliance is critical to protect user data, maintain system integrity, and uphold regulatory and contractual obligations. Non-compliance may result in review failure, project delays, or required remediation.
- Security Scanners: As part of our commitment to secure software development, InfoSec utilizes a variety of automated security scanners to assess all developed software for vulnerabilities and compliance risks. If any security findings are detected during these scans, it is the responsibility of the development team to remediate all identified issues promptly and thoroughly. Remediation is required before the software can proceed to deployment or release. Failure to address findings may result in delays, rejection of the software, or escalation to project leadership.
- 42Crunch – Scans APIs
- AquaSec – Scans container images
- Checkmarx – Static Application Security Testing (SAST) analyzes source code
- Qualys – Dynamic Application Security Testing (DAST) simulates external hacking attempts
- SentinelOne – Scans desktop applications and packages
- Security Policy: In addition to the security scanning requirements, the following SDLC requirements must be followed during software development
- Malicious Code Prevention: All code (including third-party libraries) must be scanned for malware and known vulnerabilities using automated tools (e.g. Checkmarx). Developers must not introduce logic bombs, backdoors, hardcoded credentials, or unauthorized telemetry.
- Security Documentation: Security controls, assumptions, and mitigations must be documented in the Software Requirements Document (SRD). From the available source code in EPRI repositories, a SBOM must be able to be produced documenting the composition of the project.
- Logging and Monitoring: Log security-relevant events (authentication failures, administrative actions, etc.) with sufficient context. Logs must not contain sensitive data (e.g., PII, passwords). Allow integration with centralized logging and SIEM systems for alerting and incident response.
- Secure Credential and Secret Management: Secrets (passwords, API keys, tokens) must be stored in a secure secrets manager. Passwords must be hashed using a strong algorithm (e.g., Argon2, bcrypt, or PBKDF2) with a unique salt per user. SHA-256 can be used for general hashing. Secrets must never be committed to source control.
- Authentication and Access Control: Use centralized identity providers (e.g., SSO, OAuth2, OIDC) where possible. Enforce MFA for all administrative access. Implement least privilege and role-based access control (RBAC) at all layers (application, database, infrastructure).
- Flexible Authentication Support: Applications must support pluggable authentication mechanisms (e.g., via middleware or adapters) to allow for enterprise SSO, federated identity, or legacy auth. Avoid storing credentials for external systems; use delegated tokens or short-lived credentials.
- Supply Chain Security: All dependencies must be vetted and pinned to specific versions. Subresource integrity should be implemented for all third-party scripts and styles with sha384 as a minimum hash algorithm strength.
- Input Validation and Sanitization: Validate all inputs, enforce limits on length and expected character sets. Reject requests with unexpected content-types. Encode all dynamic data before output.
- OWASP Top Ten and Beyond: Applications must be tested for vulnerabilities with automated DAST/SAST tools in CI/CD pipelines. Applications should be hardened against the vulnerabilities in the latest OWASP Top Ten and OWASP API Security Top Ten.
- Session Management: Secure and HTTPOnly flags are required for session-related cookies in web applications.
- Security Headers: Enforce HSTS and Clickjacking protections in web applications.
- HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains
- Clickjacking: X-Frame-Options: DENY or SAMEORIGIN
- Secure Coding Standards: Developers must follow language-specific secure coding guidelines (e.g. OWASP Cheat Sheets) and/or adopt a language-agnostic standard such as the 12 Factor App methodology, a set of broad conceptual solutions to systemic problems with modern SaaS applications.
You may proceed to the Software Development Process