Software Development Lifecycle Clause Samples

Software Development Lifecycle. The Cendyn Software Development Lifecycle (SDLC) describes the processes in place to develop software in a secure manner. The SDLC model consists of several distinct stages including planning, design, building, testing, and deployment with security throughout the development process. Below is an outline of how we handle updates to Cendyn products. ● Planning and Requirements Analysis - Requirement analysis is performed by the senior members of the team with inputs from the customer and product subject matter expert. This information is then used to plan the basic project approach. - Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. ● Defining Requirements - Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the Customer and/or the product manager. This is done through a BRD (Business Requirements Document) or other agile artifacts which consists of all the product requirements to be designed and developed during the project life cycle. ● Designing the change to product architecture (if required) - BRD is the reference for product architects to come out with the best architecture updates, if required. The design approach for the updated architecture is proposed and documented in a DDS – Design Document Specification. - This DDS is reviewed by all the important stakeholders and based on various parameters such as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product. - A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third-party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS. ● Building or Developing the Product - In this stage of SDLC the actual development starts utilizing the Agile Model and product changes commence. The programming code is generated as per DDS during this stage. - Developers will follow Cendyn development guidelines. ● Testing the Product - While all stages have testing, this stage refers to the testing only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the BRD. ● Deplo...

Software Development Lifecycle. For supplies that includes software development, the Vendor shall establish a Secure Software Development process. (i) adopt a Secure Software Development Lifecycle approach according to well known standards, such as IEC 62443 4-1. A certification is expected. (ii) provide evidence that identified security requirements and corresponding security controls are designed and implemented into the software. (iii) ensure that appropriate security tests including but not limited to static and dynamic code checks and continuous vulnerability assessment are applied in the development and integration pipelines and any issues uncovered are remediated before software release; and (iv) allow Customer and/or its agents to carry out Vulnerability Assessments of the developed software. If any vulnerability with a risk score of “high” or “critical” is found by the Customer, the Vendor shall take action to mitigate the risks before the software release.

Software Development Lifecycle. 8.1 Supplier must use industry standards such as BSIMM, NIST, OWASP, etc. to build in security for its Systems Development Lifecycle (SDLC). 8.2 Supplier must use an automated source code analysis tool to detect and remediate security defects in code prior to production deployment. 8.3 Manual penetration testing for applications which are internet-facing or provided to Anthem members through Anthem portals or mobile applications on behalf of Anthem must be performed by qualified testers which may be third party or internal workforce with appropriate credentials. 8.4 Supplier must have policies and procedures in place to triage and remedy reported bugs and security vulnerabilities for the products/Services it provides to Anthem. 8.5 Supplier must have controls in place to prevent unauthorized access to its or Anthem’s application, program, or object source code and ensure that access is restricted to authorized Personnel only. 8.6 National identifiers or Social Security Numbers must not be utilized as User IDs for logon to applications. 8.7 Suppliers providing products or Services related to Anthem's members through Anthem member portal or mobile applications, especially those which are internet-facing, or use Anthem domains, must participate in Anthem Information Security's Vendor Application Security Program. Supplier agrees to remediate vulnerabilities identified during this process in a manner and timeline acceptable to Anthem. 9.1 All Anthem Confidential Information, whether such information is in paper, electronic or other form, requires secure disposal or destruction when no longer required. When requested by Anthem or upon the termination or expiration of the Agreement, Supplier must return to Anthem a valid copy of its Confidential Information. After receiving confirmation from Anthem that it has received the valid copy, Supplier must delete Anthem Confidential Information on its systems using security techniques consistent with accepted standards such as NIST 800-88 Guidelines for Media Sanitization. If media containing Anthem Confidential Information is to be reused then that device shall be sanitized according to NIST SP 800-88 Guidelines for Media Sanitization before it may be used by Supplier for any purpose.

Software Development Lifecycle. The storage services are developed using a standardized and reviewed secure software development life cycle to reduce the risk of introducing security vulnerabilities into the storage services.

Software Development Lifecycle. SCN’s software is developed using C# and ▇▇▇.▇▇▇ and runs on Windows Servers using Microsoft SQL Server as the data store. As code is written it is checked by VeraCode, a static code analysis tool which identifies any vulnerabilities that may have been written into the codebase by developers. Security Testing of beta releases are undertaken by the security Architect. Internal Pen Testing is undertaken at every major release by SCN. SCN’s philosophy is defence in depth. All data is encrypted using TLS 1.2 to servers, a Web Application Firewall analyses the requests to reject any injection or client-side attacks, and IIS is set to implement the strongest security available. Code is scanned by VeraCode, ▇▇▇.▇▇▇ security is enabled, all internal traffic is sent over HTTPS, and all the data in the database is encrypted, both in transit and at rest. Transparent Data Security, TDS, in SQL Server is used to achieve this. Backups are taken every day and managed by the cloud provider. This ensures that there is no member of staff at SCN who could delete backups. Backups are available for 6 months. Transaction logging is used to enable any problems with data after the last backup and before the next. SCN’s applications are delivered as off the shelf, Software as a Service solutions, SAAS. Customers have their own Website and Database implementation on our infrastructure which is provided by UKFast. Data is stored in two datacentres, on either side of the city of Manchester, to ensure availability. All hardware infrastructure is mirrored in each datacentre. One datacentre acts as the failover - all activity in the prime datacentre is immediately updated to the failover datacentre in real time.

Software Development Lifecycle