Secure Development Lifecycle (SDLC)

The LMS365 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 LMS365 developers in building more secure software. The practices lessen the number and severity of software vulnerabilities and, hereby, ensure LMS365 fulfills compliance requirements and can assure customers and partners that security has been embedded into the development process of the LMS365 product.

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


In this article 


Secure code training

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

At least annually, LMS365 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

LMS365 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 labeled 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.

LMS365 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 LMS365 development team, prior to compilation.

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


Dynamic Analysis Security Testing (DAST)

An automated penetration and continuous scanning of the packaged software, configurations, and settings, is running regularly as part of the LMS365 software release cycle to test the security when all code is integrated and running. 

The test engine stays up to date on the behavior of hackers and cybersecurity patterns to identify any new potential risks.


Penetration testing

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

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


Quality Assurance

Our Quality Assurance (QA) department reviews and tests our codebase. Dedicated application security engineers identify, test, and triage security vulnerabilities in the code.


Framework security controls

LMS365 leverages the latest Microsoft .NET Core 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 LMS365 production environment. No customer data is used in any of our development and/or test environments.


Was this article helpful?
1 out of 1 found this helpful