Supplier Information

Anti-Corruption Standards

You will not take any action that would violate the United States Foreign Corrupt Practices Act, the UK Bribery Act 2010, any anti-corruption or similar act of any country applicable to your activities, and any rules or regulations thereunder, and any established corporate policies of McGraw Hill regarding foreign business practices ("Anti-Corruption Laws") or these Anti-Corruption Standards. As one of McGraw Hill's suppliers, you and your employees, agents and affiliates will comply with these Anti-Corruption Standards.

Anti-Corruption Laws.
You will comply with Anti-Corruption Laws. You will not take any action that would cause you to be in violation with Anti-Corruption Laws, including, without limitation, the use of any corporate funds for unlawful contributions, gifts, entertainment or other expenses or payments relating to political activity; making, attempting to make, offering, or authorizing any unlawful payment, thing of value, bribe, rebate, payoff, influence payment, kickback or other similar unlawful payment to a "Foreign Official" (including, without limitation, any officer or employee of a government at any level or of a controlled enterprise thereof or of a public international organization, or a person acting in an official capacity for or on behalf of any such government or public international organization, or a candidate for political office, or a political party or party official), for the purpose of influencing an act or decision (including a decision not to act) or inducing such a person to use his or her influence to affect any such governmental act or decision to obtain, retain, or direct any business or otherwise as prohibited by any applicable Anti-corruption Laws.

Gifts.
You will not give or promise to give anything of value either directly or indirectly to any person to improperly obtain or retain business, gain improper business advantage or improperly influence any business decision. This prohibition applies whether the intended recipient works in the public or private sector. You will not accept or agree to accept anything of value in exchange for influencing a business decision or where the recipient would be placed under a real or perceived obligation to the giver.

Record Keeping.
You will not make false or misleading entries in your books (including entries that fail to reflect improper transactions), make entries that are falsified to disguise improper transactions or fail to record payments made by or to you.

Audits.
McGraw Hill may select an independent third party to conduct an audit to certify that you comply with these Anti-Corruption Standards, as set forth in the audit section of the agreement(s) between you and McGraw Hill regarding your provision of services to McGraw Hill.

Supplier Status.
You are not owned wholly or in part by a government, any agency or instrumentality thereof, or any government official. None of your owners, partners, officers, directors, or employees, or any of your affiliates is an official or employee of the government or affiliated with an individual or entity that is on the United States Specially Designated Nationals List (SDN). You will provide written notice to McGraw Hill if your status changes.

Reporting Breaches

Any failure to comply with McGraw-Hill's Supplier Code of Business Ethics or Anti-Corruption Standards should be reported to McGraw-Hill immediately.

If you have reason to believe that a supplier working on behalf of McGraw-Hill may have violated McGraw-Hill's Supplier Code of Business Ethics or Anti-Corruption Standards, or otherwise have reason to believe that such person has engaged in ethical or legal misconduct, report such violations to McGraw-Hill at –

1-888-415-8381 (US).

Or

http://hotline.mheducation.com

To the extent possible, any report submitted to McGraw-Hill will be treated as confidential and anonymous.

Technology Standards for Third Party Developers on AWS

Cloud Standards

Hosting

Unless the software solution is delivered as a fully SaaS solution, MH requires that all components be hosted on a McGraw Hill owned AWS cloud account with our AWS organization. 

• McGraw Hill utilizes AWS Organizations and Control Tower to group related applications into separate account structures. There will be one production and one non-production account provided. All software development activity must occur exclusively in the non production account. 
• All web applications or services relying on HTTP protocols must be delivered via a McGraw Hill owned domain name. No third party domain ownership is permitted.
• McGraw Hill utilizes a split-DNS model where non-production sites are not exposed to the public internet and operate on an internal onlydomain accessible only by VPN.
• If AWS does not provide a service or capability that meets the business objective, McGraw Hill will support Azure services. Written approval to utilize Azure is required.
• Access to AWS is provided by McGraw Hill through an OKTA controlled account. Developers will authenticate via OKTA to an AWS SSO Landing page or access key.
• MH utilizes three tiers of access policy when granting IAM user access via OKTA. Requests are submitted and tracked via MH Assist
  • Read Only: Can view most AWS services. 
  • Protected: Write permissions for common services such as EC2, RDS, or S3. 
  • Power User: Most AWS services are configurable with the exception of network or account level controls. 
• If the solution requires a server, MH provides several base AMI instances, and only MH provided AMIs are permissible. AMIs are required to be rotated monthly. The following types are available: 
  • ECS Base AMI for ECS applications
  • EKS Base AMI for EKS clusters
  • Amazon Linux 2 AMI for non-dockerized workloads
  • Windows AMI for Microsoft Windows.

Tagging

In order to perform proper automation and cost reporting, McGraw Hill mandates the use of cloud assets tags to be applied during asset creation, typically via Terraform. 

Development Lifecycle

• Software is required to be tested and promoted via test environments. The best practice is DEV -> QA -> PROD.
• We enforce prod / non-prod isolation. Production services are not permitted to call endpoints registered within a non-prod account, nor are non-prod services permitted to utilize production services unless an exception is granted. 

Automation

• While hand provisioning of cloud resources is to be expected in a sandbox, once an application begins participating in SDLC, we require the use of infrastructure-as-code automation. We have standardized on Terraform, and have a number of shared modules for the most commonly supported container-based hosting patterns (e.g. ECS or EKS, Serverless, ALB, Cloudfront, API Gateway, Aurora or RDS, Open Search, ElastiCache, and other common AWS services. We also support Terraform in Azure. 

Authentication

• AWS logins are least-privileged based, where we register you with AWS SSO (which creates chained IAM users) . You will be grouped in either read only (limited console view), protected (you can start/stop most common services) or power user (most activities permitted). We utilize AWS Organizations, which includes Control Tower and SSM as a governance wrapper, so any action that would result in network or security changes that would place an account at risk are prohibited and prevented as part of account guardrails.
• Users in Azure are provisioned on an as-needed basis, with permissions crafted around the business case with subscription access likewise scoped.
• All access is audited and monitored.

Network Controls

The application will be deployed into a segmented AWS account that connects to shared services using the transit gateway. All accounts in McGraw Hill utilize pre-provisioned network segments. These are centrally managed to ensure the stability and reliability of McGraw Hill’s Enterprise infrastructure and are immutable. Each AWS account contains three public and three private subnets spread across availability zones. Network CIDRs are constrained to /21 or /22 segments. Requirements for larger network segments should be carefully planned and negotiated with Cloud Operations and Engineering.

• As an established best practice, all software deployments must utilize HA configurations spread across three availability zones to ensure reliability. This requires a minimum of two instances in two availability zones which guarantee redundancy. More complex applications may require more instances spread across the three availability zones to ensure Raft consensus. [1]

Software Development Standards

McGraw Hill prefers and supports OpenSource language frameworks. Supported serverside languages include Java, Node.js, PHP, and GoLang. Angular is the primary client-side language. Data functions are supported by Python or Scala.

Utilization of McGraw Hill Shared Services

McGraw Hill operates a shared technology microservice architecture that all applications that are customer-facing are required to utilize directly or through an LTI implementation wrapper. This platform provides common, reusable services exposing REST endpoints acting upon a single educational entity. McGraw Hill has standardized on an asset identification standard known as “XID” which serves as a globally unique identifier. Applications are not to develop their own implementations of these common services and must instead utilize the McGraw Hill Shared platform.

A full list is available outside of this document, but a common subset are:

• Login and Landing page: McGraw Hill has a common login flow for all customers and no web application shall create a unique login experience unless specifically authorized in the SOW
• Video Playback: Accessible and flexible video playback support.
• IDM (user management), ORG (educational hierarchies such as district/school).
• Roster (section/class), product (digital representation), entitlements (license/consumption)
• Scout (service configuration utility), Tass (service and user session tokens), LTI interoperability wrapper suite.

All microservices emit data through events onto a data backbone. New applications may subscribe to topics if required to cache data and respond to state change. Otherwise, all calls are to be made synchronously. No PII data may be stored in the third party application unless approved in writing.

Application design and architecture is expected to adhere to industry best practices, as expressed by the twelve-factor methodology. System architecture and flow diagrams are required and must be reviewed/approved by McGraw Hill designated staff.

1EdTech Learning Tools Interoperability (LTI)

Learning Tools Interoperability | 1EdTech

Product requirements may dictate that the software component be delivered as a LTI Tool. For external LMS platform integrations, MH provides a 1EdTech-certified LTI Advantage integration service, which internal tool providers access via the LARS integration service. LARS provides all LTI Advantage integration capabilities and services, via an LTI-compatible integration layer, which supports multiple LTI versions and security frameworks. Most MH Platforms are LTI 1.3 compatible. LTI 1.3 compatibility may be utilized in place of the shared service API integration. Adapter frameworks are available to serve as an abstraction layer between third party software components and LTI services.

Build and Configuration Management

• All build, compilation, test, validation, and deployments into a cloud platform must occur via continuous integration jobs orchestrated by GitHub Actions.
• All artifacts produced by these builds must be stored in JFrog Artifactory, which is a private container/artifact repository hosted by McGraw Hill. These artifacts will be scanned during storage to ensure they are malware/virus free. Teams are expected to utilize SonarQube for SonarQube OWASP Top10 plugin for static security scans.
• Release communication and validation is established via the JIRA ticketing system and any production changes must follow the McGraw Hill change control process.
• Database deployments are automated and managed within source control.
• All environments use the same build artifacts and configuration is injected by the environment.
• Builds and deploys must not incur downtime in production.
• When developing solutions for an existing platform, the delivered solution shall adhere to the Lint rules established for the target platform. 

Security

• End to end Encryption is required. Data must be encrypted in transit and at rest in both addressable storage and offline backups.
• Software is scanned for common vulnerabilities through a combination of static and dynamic scanning. This begins once the software is deployed into a non-prod environment and has an endpoint available for scanning. The supplier will coordinate with the McGraw Hill CyberSecurity intake process to provide credentials for test scans. Sev1 and Sev2 defects must be remediated.
• Additional pen testing exercises are performed by a third party and may result in additional issues for remediation.
• No secrets are permitted to be stored in GitHub. 

Instrumentation and Telemetry

• All running software must be observable. The preferred vendor-neutral way is to utilize OpenTelemetry and FluentBit/D for log shipping. We currently utilize New Relic as our primary APM platform, so if the software is not yet instrumented, it is a requirement to install New Relic agents for host monitoring, as well as establish Synthetic tests. Web delivery systems must install the New Relic browser beacon, as well as the Pendo agent if integrating with a licensed platform.
• Log stream data is routed to Datadog, which is our logging platform.

Service Level Objectives

In order to objectively measure software quality and end-user experience, the following golden signal indicators are utilized and measured over a 30 day period:

• Latency: Applications must perform with less than 3.0 seconds of observable render latency as measured from LargestContentfulPaint in browser DOM. Synchronous services are expected to resolve an HTTP transaction in less than 500ms, with 100ms being the target mean. These numbers must be achieved 95% of the time.
• Error Rate: HTTP responses outside of 200 or 4xx normal flow codes are not to exceed 1% rates.
• Uptime: Applications are expected to be available with successful responses at a rate of 99.95%.
• Security: Applications are required to be free of Critical and High CVE Vulnerabilities, and any security defect with a rating of P3 or higher priority must be resolved.
• Cost Efficiency: Applications are required to achieve the 4 standards above while striving to minimize operating costs. This is measured by the cloud provider's cost optimization tooling. Applications are evaluated for cloud-native scaling behavior where workload costs should closely mirror the transactional volume established by user interactions.

Source Control

Unless otherwise stipulated in the mutually signed statement of work, the following conditions apply:

• All source code developed for McGraw Hill LLC must reside in the corporate GitHub Enterprise Account and become the sole property of McGraw Hill. Source code includes application code, configuration, terraform, and any other textual configuration files necessary to compile, test, and deploy software to a cloud environment.
• Developers committing code to GitHub must use individually named accounts protected by OKTA. Shared accounts are not permissible.
• Do not store secrets in GitHub. Use AWS parameter store or Secrets Manager.
• Unit Tests of sufficient coverage (80% recommended) are required to enable automated deployment verification.
• Capacity Plan tests scripted in order to generate system stress up to 1.5x baseline throughput are required.