Secure Coding and Application Security

Standard number: DS-18
Date issued: 7/1/2018
Date last reviewed: 6/1/2024
Date of next review: 6/1/2026
Version: 1.1
Approval authority: Vice President for Information Technology and CIO
Responsible office: Information Assurance

This Standard supports and supplements the Information Security (SPG 601.27) policy. It will be periodically reviewed and updated as necessary to meet emerging threats, changes in legal and regulatory requirements, and technological advances.

I. Overview

Insecure software coding and web application design can leave data and IT systems vulnerable to exploitation. This standard seeks to ensure that applications developed or administered by the university reflect secure coding practices, which can reduce likelihood that malicious code will be inserted in software, and lessen the impact of malicious code that is already present in deployed software.

Implementation of this standard can:

• Reduce the likelihood of unauthorized disclosure or theft of sensitive institutional information;
• Prevent unauthorized access to administrative interfaces or systems;
• Increase compliance with legal and regulatory requirements;
• Ensure the ongoing availability of critical university assets and resources;

This Standard lays out requirements and expectations so that security controls applied to applications will result in a level of risk that is appropriate when considering the sensitivity classification of data being processed, stored, and transmitted.

Federal or state regulations or contractual agreements may require additional controls beyond those included in this Standard.

II. Scope

This standard applies to the Ann Arbor campus, Michigan Medicine, UM-Dearborn, UM-Flint, all affiliates, and all faculty, staff, workforce members, and sponsored affiliates. It also applies to:

• All units, faculty, principal investigators, staff, and workforce members that create, process, maintain, transmit, or store data classified as Restricted, High, or Moderate on any device.
• Software and web applications including mobile applications, irrespective of the application developer or the device used for programming, that run on physical or virtual hosts (including third-party cloud or datacenter hosts).
• Third-party service providers contracted by U-M to perform application development that involves data classified as Restricted, High, or Moderate.

III. Roles and Responsibilities

University units must adhere to the requirements of this Standard in all instances that involve data classified as Restricted, High, or Moderate, and ensure, as best as possible, that in-house software and application developers are provided with adequate resources that allow for prioritizing implementation of this Standard’s security controls.

Software and application developers and administrators must ensure that secure coding practices are incorporated into each phase of the software development life cycle. They are responsible for reviewing the code and implementing appropriate application security controls for systems under their management and supervision.

IV. Standard

The essential components of secure coding and application security include:

1. Software/Application Patching: The timely and consistent application of vendor-supplied security patches or mitigation of a reported vulnerability, in accordance with the Vulnerability Management Standard, are critical components in protecting the campus network, systems, and data from damage or loss due to threats such as worms, viruses, data loss, or other types of external or internal attacks.
2. Use of Production Environments: A Production Environment contains an application or service deployment that is ready and approved for its intended use by end users or other systems. The Production Environment must meet all standards for the classification of data that it contains.
3. Use of Pre-Production/Quality Assurance/Staging Environments: A Pre-Production/Quality Assurance/Staging Environment contains an application or service deployment undergoing final verification before being deployed into a Production Environment. A Pre-Production/Quality Assurance/Staging Environment meeting all standards for the corresponding Production Environment may contain data of the same data classification as the target Production Environment.
4. Use of Test Environments: A Test Environment is any service or application deployment that uses software, configurations, or infrastructure that have not been fully approved for production use. As an example, software that is still in development and has not undergone thorough security testing could be considered part of a Test Environment. Data classified as Restricted or High may not be used in Test Environments without Information Assurance (IA) permission. It is not recommended that data classified as Moderate be used in Test Environments.
5. Use of Development Environments: A Development Environment, unlike the Production, Staging, and Test environments, is sometimes run from a software developer’s desktop or laptop system. Software and configurations in such an environment are typically in various stages of construction and should not be trusted to secure data. Therefore, a Development Environment must adhere to the same standards as a Test Environment.
6. Secure Coding: Secure coding practices should be incorporated into the university’s security architecture and development lifecycle. This includes defining security requirements early in the software development life cycle and then evaluating for compliance with those requirements.
7. Software and web applications that fall under this Standard are required to meet the OWASP Secure Coding Guidelines or their equivalent. Some of the most important secure coding practices are highlighted in the table below.
8. Reliance on External or Third-Party Components: 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 available version in order to ensure that all known vulnerabilities with available patches will be addressed.
9. Dynamic Inclusion of Software: Some software dynamically includes 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 the developer has no control. This should be avoided since the dynamically included code may not meet all standards for the class of data in the application.

In addition to the requirements of this Standard, applications, databases, and APIs that maintain, process, transmit, or store data classified as Restricted or High must also be in compliance with the Security of Enterprise Application Integration Standard (DS-09).

V. Violations and Sanctions

Violations of this Standard may result in disciplinary action up to and including suspension or revocation of computer accounts and access to networks, non-reappointment, discharge, dismissal, and/or legal action. In addition, the connectivity of machines and servers to the U-M network that do not comply with this Standard may be limited or disconnected.

Discipline (SPG 201.12) provides for staff member disciplinary procedures and sanctions. Violations of this policy by faculty may result in appropriate sanction or disciplinary action consistent with applicable university procedures. If dismissal or demotion of qualified faculty is proposed, the matter will be addressed in accordance with the procedures set forth in Regents Bylaw 5.09. In addition to U-M disciplinary actions, individuals may be personally subject to criminal or civil prosecution and sanctions if they engage in unlawful behavior related to applicable federal and state laws.

Any U-M department or unit found to have violated this policy may be held accountable for the financial penalties, legal fees, and other remediation costs associated with a resulting information security incident and other regulatory non-compliance.

VI. Implementation

Information Assurance is responsible for the implementation, maintenance and interpretation of this Standard.

VII. References

• OWASP Secure Coding Guidelines (2010)
• Security of Enterprise Application Integration (DS-09)

VIII. Related NIST Security Controls

• NIST SP 800-53 Revision 5
  • SA-03 System Development Life Cycle
  • SA-08 Security and Privacy Engineering Principles
  • SI-11 Error Handling