AdaCore Security Policy

Mission

AdaCore’s mission is to help people build software that matters.

We serve customers globally, in civilian and defense-related industries, by building and maintaining tools and providing services that assist with developing high-integrity software. We also participate in collaborative research and development projects.

AdaCore products are part of the supply chain for customers that have strong security requirements and handle classified information. AdaCore provides a compilation toolchain, IDE, static and dynamic analysis tools, and code generation tools.

AdaCore’s information security management system covers all of AdaCore’s operations:

  • Research, development, production, and support;

  • Marketing and sales;

  • Supporting activities (e.g., human resources, administrative, finance, procurement)

Organizational security

Awareness training

All teammates receive security awareness training when they first join AdaCore. The training topics include

  • Phishing awareness

  • Password management, how to generate secure passwords, and the importance of 2FA

  • Importance of session locking, and disk encryption

  • Privacy issues: all employees also receive a GDPR training

  • Insider threats, and, in particular, how to recognize threats that may come from inside AdaCore

All users of our information system must read and sign AdaCore’s Acceptable Use Policy prior to being given access to AdaCore data. That document outlines rules and guidelines for accessing AdaCore information.

After this initial training, all staff receive internal information security newsletters reminding them of best practices, informing them of required actions they must perform, and providing general security advice.

The security team also regularly conducts assessments to ensure that the Acceptable Use Policy is well understood and that users comply with AdaCore's information security policy.

Incident Response

Team

There are two teams responsible for incident response at AdaCore: the Computer Security Incident Response Team (CSIRT) and the Product Security Incident Response Team (PSIRT). The CSIRT team responds to security incidents impacting our information system, whereas the PSIRT team reacts to incidents occurring in our Software Supply Chain and potentially affecting our products.

Security Incident Responders train the team to respond to security incidents. Tabletop exercises are regularly performed to test the incident response process. Security Incident Responders have direct knowledge of AdaCore operations and can act quickly in case of unexpected events.

Detection

Automated

We have several alerting systems that detect unusual activity within our networks or in our cloud-based APIs. We have deployed an intrusion detection system based on hardware and software canaries at various endpoints and we receive instant notifications when the canaries are triggered.

AWS GuardDuty monitors our cloud-based APIs.

We rely on Data Loss Prevention systems to detect potential leaks.

Manual

Security events detected by staff are reported to security@adacore.com, product-security@adacore.com, or through our Security Portal. All options reach AdaCore security staff. A Security Incident Response Checklist is available to help identify the severity and actions to be taken in such cases.

Incident handling

When an incident is suspected, the security incident response team follows a predefined incident response plan and communicates with the relevant stakeholders to perform an investigation. If necessary, impacted customers will be notified by our support team.

Reducing potential security breaches

This policy, and all cybersecurity efforts, protect AdaCore's data, products, and customers, with particular focus on the following risks:

  • Financial losses: Cybersecurity breaches can lead to substantial financial losses, including legal fees, incident response, data recovery, and compensation to affected parties.

  • Reputational damage: Publicized breaches can damage an organization's reputation, eroding customer trust and loyalty.

  • Legal and regulatory consequences: Breached entities may face legal and regulatory consequences, especially if they fail to comply with data protection laws and regulations.

  • Operational disruptions: Cyberattacks may disrupt critical services, affecting business operations and causing economic losses.

  • Data theft and privacy violations: Breaches can lead to the theft of personal information, leading to identity theft and privacy violations.

  • Intellectual property theft: Attacks targeting intellectual property can result in stolen trade secrets or proprietary information, damaging a company's competitive edge.

Assets management

Although only data identified as confidential and code submitted as part of a support request are considered confidential under the terms of our agreements with customers, our policy is to nevertheless treat all significant data from customers as if it were confidential unless it’s clear that it’s not. Data is stored on AdaCore servers hosted at an Equinix data center in France, on cloud systems controlled by AdaCore, on AWS and Google Cloud, and on some trusted third-party services such as Salesforce and ServiceNow.

See Third Party Services Storing Customer Confidential Information for the list of third-party services.

IAM (Identity and Access Management)

We maintain an access management system based on an RBAC (Role-based Access Control) approach. AdaCore security engineers validate all changes to our centralized access control database. We perform regular audits to ensure that users have only the minimum set of permissions to perform their work. Our RBAC system is connected to our HR database to reflect role changes automatically. People leaving AdaCore have their accounts immediately suspended.

We carefully limit the number of administrators with wide elevated privileges and notify all administrators when changes requiring high-level access are performed (principle of least privilege).

Secure Supply Chain

Our build system ensures full traceability from source code repositories to the final product delivered to customers. This traceability information enables the generation of SBOMs (software bill of materials) for all of our products and allows us to scan regularly for CVEs associated with software components we depend on.

Our builds are performed on ephemeral machines that have no inbound access. Not even the IT administrators can connect to a production instance. Outbound traffic is also strongly restricted, and we ensure machines only have access to internal APIs they need, e.g., to access our internal package registries or version control repositories.

We employ anti-virus software to protect our software production pipeline. Each third-party package is first checked with VirusTotal internal submission. We scan all binaries pushed to our artifact store with Windows Defender and ClamAV.

Business continuity

We have created Disaster Recovery and Business Continuity Plans to allow our critical business processes to continue, even if in a degraded mode, in the face of most potential failures. As part of our Disaster Recovery Plan, we regularly test recovering our backups to ensure prompt recovery of our systems in case of an incident. Our staff can work fully remotely if something prevents them from physically accessing AdaCore offices.

We rely on trusted and robust third-party providers such as Salesforce, ServiceNow, Google Workspace, and AWS. All custom AdaCore production build and test infrastructure is maintained as code and can be redeployed quickly if the need should arise.

Compliance

AdaCore is NIST SP 800-171 and GDPR compliant. A full audit of our information system is performed annually, and a PoAM manages all deviations from our privacy and security policies.

AdaCore policies in support of our compliance efforts are reviewed regularly.

We are pursuing compliance with NIST Guidance mentioned in Executive Order 14028 with the implementation of new processes such as SLSA Build Level 3 compliance.

Physical security

AdaCore offices

AdaCore has two corporate headquarters, located in NY and Paris. AdaCore’s staff is also present in satellite offices located in the UK, Estonia, Germany, and France. Access to the corporate headquarters requires the use of an individual access token that can be remotely deactivated (loss, theft, etc).

AdaCore machine room

Most of the physical servers owned by AdaCore are running in a data center managed by Equinix. Equinix is responsible for the physical security of these systems.

AdaCore runs EC2 instances on AWS and relies on AWS physical security in accordance with the AWS shared responsibility model.

Encryption at rest is enforced on all servers.

User devices and external services

All user devices accessing AdaCore information servers are encrypted at rest and have an auto-locking mechanism. AdaCore enforces SSO and 2FA for our cloud services when provided by the third-party service. Enforcing such additional protection is particularly the case for the services hosting confidential customer information and all services maintained directly by the AdaCore IT staff.

Workstation security

Workstations Configuration Baseline

We use CIS Benchmarks to generate secure OS images and review controls annually at a minimum.

Password Management

Our employees are required to use 1Password.

We audit permissions on a monthly basis or when there’s a change in the staff organigram.

We limit the number of passwords we use and replace them with short-lived credentials when possible. See https://blog.adacore.com/identifying-and-authorizing-users-at-adacore for more information.

Anti-virus software

Computers running Windows are protected using Windows Defender. Those running macOS are protected by Sandbox and Gatekeeper (see https://www.apple.com/fr/macos/security/).

Only software coming from sources approved by AdaCore security may be installed on user workstations. Developers sometimes need more freedom when it comes to software they can locally build on their workstations. The IT Security team maintains a guide helping developers assess whether they can safely download third-party software and engineers are strongly encouraged to solicit the input of the security team before obtaining new software.

Data Protection

Encryption at Rest

We rely on BitLocker, LUKS, and FileVault to encrypt user drives. Our physical servers use SEDs (self-encrypting drives).

Secure boot

All Macbooks purchased after Feb 2019 benefit from Apple T2 security; see https://support.apple.com/en-us/102522.

All other systems that support secure boot have it enabled.

Firewall

We activate the OS firewall by default. See https://support.apple.com/en-us/HT201642 for Apple systems, and Windows Defender Firewall for Windows systems.

Memory

We require ASLR (Address Space Layout Randomization) and DEP (Data Execution Prevention) on all our servers and workstations.

Product security

Continuous integration and product delivery

AdaCore requires a code review for all changes or additions of external dependencies to the source code of AdaCore products or our build and test system. In addition to all tests performed automatically after each push to our Git repositories (which are hosted on a private Gitlab instance), we also perform a full rebuild of all our tools on a daily basis. These builds are validated by hundreds of thousands of tests performed on various CPU and OS architectures. All build and test results are pushed to the AdaCore Product Engineering team, which analyzes all failures and opens internal issues to remediate all detected errors.

Product delivery is done through our GNATtracker portal, which uses the facilities and services of ServiceNow. Customers with a valid account can access that portal and all data is transferred through HTTPS (HyperText Transfer Protocol over TLS), ensuring data is encrypted in transit.

Official Release

In addition to the automatic validation, we perform manual tests of all products prior to delivering an AdaCore release. All errors detected during the automatic and manual test activities must be analyzed and declared non-blocking for the release process to continue. When non-blocking errors are found, they must be properly documented in the AdaCore Known Problems Database and communicated to all customers of that product.