Secure Software Development Sample Clauses
POPULAR SAMPLE Copied 9 times
Secure Software Development. (a) Licensor shall ensure all Products have been developed in accordance with principles of secure software development consistent with software development industry best practices, including, security design review, secure coding practices, risk based testing and remediation requirements.
(b) Licensor must use reasonable measures to secure the software development environment of the Products from unauthorized access.
(c) Licensor shall include cybersecurity guidance in the Product documentation provided to GE. This documentation shall include guidance on how to configure the Products and/or the surrounding environment to best ensure security. It shall also include guidance on which logical or physical ports are required for the product to function. If authentication is used to protect access to any service or capability of the Products, regardless of the intended user of that service/capability, the Supplier shall ensure:
(i) the Products shall not provide access to that service or capability using a default account/password;
(ii) the Products shall not provide access to that service or capability using a “Backdoor” account or password;
(iii) the Products’ associated authentication and password change processes shall be implemented with an appropriately secure cryptographic level; and
(iv) GE shall be able to change any passwords supported by the Products.
(d) Services or capabilities that are not required to implement the Product’s functionality shall by default be disabled, or shall require authentication to protect access to this service or capability.
(e) In the event that any wireless technology is incorporated in any Product, Licensor shall document that the wireless technology complies with standard operational and security requirements specified in applicable wireless standard(s) or specification(s) (e.g., applicable IEEE standards, such as 802.11).
(f) In the event that any cryptographic systems are contained in the Product, Supplier shall only use cryptographic methods that are “Approved” as defined in the Federal Information Processing Standard (FIPS) Security Requirements for Cryptographic Modules (FIPS 140-2), and Supplier shall provide an automated remote key-establishment (update) method that protects the confidentiality and integrity of the cryptographic keys.
Secure Software Development. Well defined security process that is implemented and monitored throughout the SDLC taking into consideration confidentiality, availability and integrity requirements.
Secure Software Development. Data Importer shall maintain policies and procedures to ensure that system, device, application and infrastructure development is performed in a secure manner. This includes review and test of all Data Importer applications, products and services for common security vulnerabilities and defects, employing defense-in-depth strategy through the use of multiple layers of security boundaries and technologies, periodic pen testing and security assessment of these services, defining baseline configurations and requirements for patching of third party systems.
Secure Software Development. ServiceNow shall implement and maintain secure application development policies and procedures aligned with industry standard practices such as the OWASP Top Ten (or a substantially equivalent standard). All personnel responsible for secure application design and development will receive appropriate training regarding ServiceNow’s secure application development practices.
Secure Software Development. Cvent shall maintain processes to identify, evaluate and address risks to the development of its software solutions. Cvent shall maintain an independent test/development environment, separate from production computing resources, for any testing of new software and/or changes to existing software. Production data will not be used for software testing and development purposes unless sanitized and deemed necessary for any intended testing that needs to be performed; all efforts will be made to first utilize mock/test data. Cvent maintains a change control process for application changes pushed to production computing environments. Changes shall require approvals and specific tasks to be performed, including: Development, Code Review, Testing, Approval of Changes, and Documentation of Changes. Cvent requires all software developers to undergo training on secure coding practices in line with OWASP Top 10 guidelines.
Secure Software Development. Any new feature and product enhancement we implement goes through a security review during design. Additionally, any code committed to our code base goes through a code-review process ensuring code quality and adherence to standards. We also perform regular penetration testing and automatic scanning to validate no security vulnerabilities exist in our platform.
Secure Software Development. Talos represents and warrants that any software used in connection with the Processing of Customer Personal Data is or has been developed using secure software development practices, including: (a) segregating development and production environments; (b) filtering out potentially malicious character sequences in user inputs; (c) using secure communication techniques, including encryption; (d) using sound memory management practices; (e) using web application firewalls to address common web application attacks such as cross-site scripting, SQL injection and command injection; (f) implementing the OWASP Top Ten recommendations, as applicable; (g) patching of software; (h) testing object code and source code for common coding errors and vulnerabilities using code analysis tools; (i) testing of web applications for vulnerabilities using web application scanners; and (j) testing software for performance under denial of service and other resource exhaustion attacks.
Secure Software Development. Supplier shall implement and maintain secure application development policies and procedures aligned with industry standard practices such as the OWASP Top Ten (or a substantially equivalent standard). All personnel responsible for secure application design and development will receive appropriate training regarding Supplier’s secure application development practices.
Secure Software Development. Company represents and warrants that any software used in connection with the processing of Customer’s Confidential Information is or has been developed using secure software development practices, including: (a) segregating development and production environments; (b) filtering out potentially malicious character sequences in user inputs; (c) using secure communication techniques, including encryption; (d) using sound memory management practices; (e) using web application firewalls to address common web application attacks such as cross-site scripting, SQL injection and command injection; (f) implementing the OWASP Top Ten recommendations, as applicable; (g) patching of software; (h) testing object code and source code for common coding errors and vulnerabilities using code analysis tools; (i) testing of web applications for vulnerabilities using web application scanners; and (j) testing software for performance under denial of service and other resource exhaustion attacks.
Secure Software Development. 11.1 The 3rd Party must ensure that production and non-production environments are appropriately controlled by ensuring the following components are in place: • Segregation of production and non-production environments with segregation of duty. • No live data to be used in test unless prior agreement from the data owners and controls commensurate with the production environment. • Segregation of duties between production and non-production development.
11.2 The 3rd Party must have an established and consistent Systems Development framework to prevent security vulnerabilities and Cyber Security breaches which contains the following components: • Systems are developed in line with Secure Development best practice (e.g., OWASP). • Code is securely stored and subject to Quality Assurance. • Code is adequately protected from unauthorised modification once testing has been signed off and delivered into production.