Secure Development Life Cycle (SDLC)

The EUM Secure Development Lifecycle (SDLC) is inspired by Microsoft's Security Development Lifecycle Practices and is made up of a set of practices that support the EUM developers in building more secure software. The practices lessen the number and severity of software vulnerabilities and, hereby, ensure EUM fulfills compliance requirements and can assure Customers and partners that security has been embedded into the development process of the EUM product. 

In this article, we will describe the set of practices in the EUM SDLC.  

In this article:

  • Secure code training 
  • Security quality level standards and reporting 
  • Management of security and license risk of third-party components 
  • Static Analysis Security Testing (SAST) 
  • Penetration testing 
  • Quality Assurance 
  • Framework security controls 
  • Separate environments 


Secure Code Training 

It is important that the people building the EUM product understand security basics and are aware of how to build security into software to prevent attempts from attackers and create a more secure product.  

At least annually, EUM software engineers participate in secure code training covering the Open Web Application Security Project (OWASP) top 10 security risks, common attack vectors, and Azure security controls. 


Security Quality Level Standards and Reporting 

EUM has defined levels of security quality to have a set standard for the minimum acceptable level of security quality and to have exact routines of how to respond to security vulnerabilities of different severity. This helps our team identify and address security defects appropriately and in due time, and to deliver a consistently high standard of security quality throughout all development phases. 

Security defects and security work items are registered and clearly labelled, allowing for clear tracking and reporting of work related to security. 


Management of Security and License Risk of Third-Party Components 

A vulnerability of a third-party component can impact the security of the larger system the component is integrated into. 

EUM has an accurate inventory of third-party components employed. Open source dependencies for known vulnerabilities are found and updated recommendations for the third-party libraries are provided, when required, to avoid vulnerabilities. 


Static Analysis Security Testing (SAST) 

To ensure secure coding policies are being followed, the source code is scanned and analyzed directly within the Integrated Development Environment (IDE) Visual Studio and the Azure DevOps build pipeline, used by the EUM development team, prior to compilation. 

Providing automated feedback and preventing any known security vulnerabilities from being added to the EUM environment, this is a scalable method of security code review that helps spot flaws at an early stage. 


Penetration Testing 

In a penetration test, skilled security professionals will simulate the behavior of a hacker to discover potential exploitable vulnerabilities. 

Software Secured automated and manual penetration tests are performed on the EUM application and underlying web applications to uncover potential coding errors, configuration flaws, or other weaknesses that can create a vulnerability in the EUM product. 


Quality Assurance 

Our Quality Assurance (QA) department reviews and tests our codebase.  They execute both automated and manual tests in a continuous integration environment.  They are also validating the deployment packages in an isolated environment to align with our client deployments.


Framework Security Controls 

EUM leverages the latest Microsoft .NET Core (Long Term Support) LTS open-source framework with security controls in place to limit exposure to OWASP top 10 security risks. These inherent controls reduce our exposure to SQL Injection (SQLi), Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF), among others. 


Separate Environments 

Development, testing, and staging environments are logically separated from the EUM production environment. No customer data is used in any of our development and/or test environments.