Latest Secure Software Deployment Checklist

Secure Software Deployment Checklist

The Secure Software Deployment Checklist is your definitive guide to ensuring a secure and seamless deployment process for your applications. Designed for developers, DevOps engineers, and IT security professionals, this checklist provides step-by-step guidance to minimize risks and maintain robust security during the transition from development to production.

Secure Software Deployment Checklist
Documentation
	Ensure that detailed documentation is available for secure deployment and Maintenance
Secure Build and Deploy
	1. Ensure that the application build, and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts. 2. Ensure that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found. 3. Ensure that server configuration is hardened as per the recommendations of the application server and frameworks in use. 4. Ensure that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion. 5. Ensure that authorized administrators can ensure the integrity of all security-relevant configurations to detect tampering. 6. Ensure that all components are up to date, preferably using a dependency checker during build or compile time. 7. Ensure that all unwanted features, documentation, sample applications and configurations are removed. 8. Ensure that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Sub resource Integrity (SRI) is used to validate the integrity of the asset. 9. Ensure that third party components come from pre-defined, trusted and continually maintained repositories. 10. Ensure that a Software Bill of Materials (SBOM) is maintained of all third-party libraries in use. 11. Ensure that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behavior into the application. 12. Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures. 13. Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
System Configuration & Hardening
	1. Ensure servers, frameworks and system components are running the latest approved version. 2. Ensure servers, frameworks and system components have all patches issued for the version in use. 3. Turn off directory listings. 4. Restrict the web server, process, and service accounts to the least privileges possible 5. When exceptions occur, fail securely. 6. Remove all unnecessary functionality and files. 7. Remove test code or any functionality not intended for production, prior to deployment. 8. Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory. Then "Disallow" that entire parent directory in the robots.txt file rather than disallowing each individual directory. 9. Define which HTTP methods, GET or POST, the application will support and whether it will be handled differently in different pages in the application. 10. Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is required, utilize a well-vetted authentication mechanism. 11. If the web server handles both HTTP 1.0 and 1.1, ensure that both are configured in a similar manor or ensure that you understand any difference that may exist (e.g. handling of extended HTTP methods) 12. Remove unnecessary information from HTTP response headers related to the OS, web-server version, and application frameworks. 13. The security configuration store for the application should be able to be output in human readable form to support auditing. 14. Implement an asset management system and register system components and software in it. 15. Isolate development environments from the production network and provide access only to authorized development and test groups. Development environments are often configured less securely than production environments and attackers may use this difference to discover shared weaknesses or as an avenue for exploitation. 16. Implement a software change control system to manage and record changes to the code both in development and production
Communication Security
	1. Verify that a path can be built from a trusted CA to each Transport Layer Security (TLS) server certificate, and that each server certificate is valid. 2. Verify that failed TLS connections do not fall back to an insecure HTTP connection. 3. Verify that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions. 4. Verify that backend TLS connection failures are logged. 5. Verify that certificate paths are built and verified for all client certificates using configured trust anchors and revocation information. 6. Verify that all connections to external systems that involve sensitive information or functions are authenticated. 7. Verify that all connections to external systems that involve sensitive information or functions use an account that has been set up to have the minimum privileges necessary for the application to function properly. 8. Verify that specific character encodings are defined for all connections (e.g., UTF-8). 9. Verify that there is a single standard TLS implementation that is used by the application that is configured to operate in an approved mode of operation
Operations and Maintenance
	1. Check whether operations manual is available, and personnel properly trained for handling smooth operations? 2. Verify whether the systems operations personnel are using various monitoring tools for traffic and illegitimate traffic and capacity usage. 3. Verify whether application leverage automation to check application and environment health? 4. Are security-related alerts and error conditions documented for most projects? 5. Verify whether project teams deliver an operational security guide with each product release. 6. Verify whether applications have a point of contact for security issues. 7. Whether the application has an assigned security response team? 8. Whether the applications consistently collect, and report data and metrics related to incidents?
HTTP Requests Security
	1. Ensure that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context. 2. Ensure that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker. 3. Ensure that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the "null" origin. 4. Ensure that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application. 5. Ensure that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. content must match with the provided Content-Type header. 6. Ensure that all API responses contain a Content-Disposition: attachment; filename="api.json" header (or other appropriate filename for the content type). 7. Ensure that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities. 8. Ensure that all responses contain a X-Content-Type-Options: no sniff header. 9. Ensure that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains. 10. Ensure that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referrer header to untrusted parties. 11. Ensure that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers.
Secure Software Updates
	1. Ensure that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update. 2. Ensure that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet. 3. Ensure that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.
Configuration Architecture
	1. Does the design segregate components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms? 2. Ensure that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices. 3. Ensure that the build pipeline warns of out-of-date or insecure components and takes appropriate actions. 4. Ensure that the build pipeline contains a build step to automatically build and verify the secure deployment of the application, particularly if the application infrastructure is software defined, such as cloud environment build scripts. 5. Ensure that application deployments adequately sandbox, containerize and/or isolate at the network level to delay and deter attackers from attacking other applications, especially when they are performing sensitive or dangerous actions such as deserialization. 6. Ensure the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.
Source: owasp.org

Suggested Exercises: Secure Software Deployment and Operations