Policy Owner: Principal Engineer
...
Proactive not Reactive; Preventative not Remedial
Privacy as the Default Setting
Privacy Embedded into Design
Full Functionality – Positive-Sum, not Zero-Sum
End-to-End Security – Full Lifecycle Protection
Visibility and Transparency – Keep it Open
Respect for User Privacy – Keep it User-Centric
Software developers are expected to adhere to CloudCard’s coding standards throughout the engineering process, including standards for quality, testing, and security.
Software and web applications are required to meet the OWASP Secure Coding Guidelines (2010) or their equivalent.
Software typically relies on other modules, components, or libraries for its functions. Any of these may contain security vulnerabilities. The application developer should use the latest possible version in order to ensure that all known vulnerabilities with available patches will be addressed.
Dynamic Inclusion of Software: CloudCard software should not dynamically include other software from other sources at runtime, such as a web application that causes the user’s web browser to fetch JavaScript from a third-party over which CloudCard has no control. If external code is required by a browser application, it should be reviewed by CloudCard and copied into a CloudCard controlled location from which the web browser can fetch the code.
Developers should also consider the following sections of NIST SP 800-53 Revision 5:
Engineering documentation and technical references can be found in the https://sharptop.atlassian.net/wiki/spaces/CCD/overview?homepageId=15859717. Software developers are expected to adhere to CloudCard’s coding standards throughout the engineering process, including standards for quality, testing, and security.
| Anchor | ||||
|---|---|---|---|---|
|
CloudCard shall establish and appropriately protect environments for system development and integration efforts that cover the entire system development life cycle. The following environments shall be logically or physically segregated:
Production
Contains applications ready and approved for use by customers and storage of customer data.
Changes are controlled and subject to prior approval and testing.
Access is restricted to users who have fulfilled the requirements of access to customer data and have a business need.
Test
Contains applications not fully approved for use by customers or storage of customer data.
Available for customers to perform validation or acceptance tests.
Must not contain customer data, except data provided by customers for the purpose of validating functionality
Changes are coordinated to ensure no conflicts between team members in use of the environment.
Local Development
Contains applications under active modification. Typically operated on a developer’s desktop or laptop.
Must not contain customer data.
| Anchor | ||||
|---|---|---|---|---|
|
...
| Anchor | ||||
|---|---|---|---|---|
|
Application code should be scanned prior to deployment. Patches to address application vulnerabilities that materially impact security should be deployed within 90 days of discovery.
| Anchor | ||||
|---|---|---|---|---|
|
...
Software developers shall be provided with secure development training appropriate to their role at least annually. Training content shall be determined by management but shall address the prevention of common web application attacks and vulnerabilities. The following threats and vulnerabilities should be addressed as appropriate:
prevention of authorization bypass attacks
prevention of the use of insecure session IDs
prevention of Injection attacks
prevention of cross-site scripting attacks
prevention of cross-site request forgery attacks
prevention of the use of vulnerable libraries
| Anchor | ||||
|---|---|---|---|---|
|
...