Yesterday, October 21, 2026 may have been one of the worst days in cybersecurity history. Here is a short list of serious vulnerabilities that were identified:

• A major vulnerability in the PHP programming language allowed for remote code execution (RCE)

• A Node.js library allowed for remote code execution

• The Platform-as-a-Service provider Railway exposed credentials for many customers

• An intermediate certificate authority (CA) had its private keys compromised

For many, these headlines and descriptions are indecipherable. Are these serious issues? Should I be worried? Is my institution safe?

We have entered a new era in software powered by the advances in artificial intelligence and large language models (LLMs). As ChatGPT, Claude, Gemini, and Copilot continue to improve in capability, they become more powerful in the wrong hands as well. These and lesser-known products have drastically accelerated the human capability to discover and exploit software vulnerabilities. Security practices that IT teams have asked us to follow (e.g., long, unique passwords, multi-factor authentication) may no longer be good enough to keep applications on the internet secure.

These models and the tools around them can be used to probe and find the smallest openings to harm web platforms and their clients.

Given this period of rapid change, I wanted to write this message to discuss Scholarly’s security practices and security practices across the software industry. This may not give you peace of mind, but it will hopefully better equip you to decide “Can Scholarly be trusted with my institution’s sensitive data?”

Scholarly Holds Sensitive Data

Clients use the Scholarly platform as a system of record for important and often sensitive faculty data. This will often include email addresses, physical addresses, phone numbers, compensation information, and sensitive processes like promotion or tenure workflows.

We take this responsibility very seriously, and it’s something our team has more than a decade of experience doing. Our engineering team comes from companies like Gusto, Amazon, and other large tech companies where the stakes are incredibly high. While we host tens of thousands of faculty members on our platform today, our team has experience developing platforms serving millions with even more sensitive data (e.g., social security numbers).

Scholarly Practices Continuous Security

Security is a daily practice at Scholarly.

Before any code can be shipped to the production application, our systems complete a series of checks to identify any potential security vulnerability. These quick checks cannot identify all issues, so we augment these with annual penetration tests and quarterly automated intrusion tests.

These security practices are asserted once per year in our SOC 2 Type II audit, where a neutral third party observes our security practices and issues a report. Our third report for the year 2026 should be ready by year’s end or early 2027. This report is available upon request and is often shared during the contracting process.

Scholarly was also recently admitted into the Daybreak Blue Program (OpenAI) and the Claude Cyber Verification Program (Anthropic). These programs allow companies like Scholarly to use state-of-the-art models to simulate attackers to proactively find and fix vulnerabilities. Through these programs, our team has already patched more than 30 issues flagged by these models. No flagged issue put customer data or processes at risk, but we patch these as a matter of Scholarly’s defense-in-depth approach.

We publish a live-updating Trust Report. This report is tied to production systems and updates should Scholarly fall out of compliance on any given control. You can see in real time if any Scholarly employee is late on their security training.

Although Scholarly’s technology stack was not affected by yesterday’s vulnerabilities, we operate with the mindset that it may be in the future. No choice of technology is safe. To combat that, we pride ourselves on quick turnarounds for these security issues. The last serious issue was patched platform-wide for all customers within 6 hours of public disclosure. We publish product updates and other security patches in our fortnightly changelog.

Scholarly Believes That Certifications Are Just a Start

Although Scholarly has received a clean audit opinion on its last two SOC 2 Type II reports, we believe certifications are just the beginning of our security practices.

The threat actors (the bad guys) don’t care if a target has a certification; they will exploit any available vulnerability. For this reason, we try to always stay one step ahead. This includes opting into leading-edge programs provided by companies like OpenAI and Anthropic. As part of our company culture, we internally share security practices that go beyond the bare minimum.

Our clients trust us with some of the most sensitive data and processes at their institution, and we take that responsibility very seriously. If you have any questions about Scholarly, our security practices, or this brave new world we are in, please do not hesitate to get in touch with us through your main Scholarly contact or through info@scholarlysoftware.com.

Kelly Sutton
Chief Technology Officer, Scholarly