Security

13 posts

gitlab3 min readCurated summary

Prepare your pipeline for AI-discovered zero-days

AI is accelerating both vulnerability discovery and insecure code production, shrinking the time defenders have to respond from months to hours. The post argues that security teams cannot remain the final defense layer; security controls, automated triage, and remediation must operate directly within development pipelines. AI-generated fixes can help close the gap, but they must follow the same policies, approvals, testing, and audit requirements as human-authored code. ## The Remediation Backlog Is Already Too Large - Most exploited vulnerabilities are already known and have patches available, but organizations cannot remediate them quickly enough. - Sixty percent of breaches in the 2025 Verizon DBIR involved known vulnerabilities. - Developers spend roughly 11 hours per month fixing vulnerabilities after release. - The median time to close half of internet-facing vulnerabilities is 361 days, while exploitation can begin within hours. - AI-assisted development is increasing the volume of insecure code: - Fortune 50 repositories reportedly gained more than 10,000 security findings per month by mid-2025. - AI coding tools may introduce outdated patterns, hallucinated packages, insecure examples, and excessive dependencies. - Security AI should therefore operate within existing development policies and audit trails rather than as a disconnected tool. ## Security Enforcement Must Move Into the Pipeline - Every change should pass security controls at the merge request, which becomes the central enforcement point. - Policies should be defined once and applied consistently across teams and projects. - Exceptions should be explicitly approved and logged. - IDE checks can catch straightforward problems—such as hardcoded secrets, vulnerable imports, and deprecated APIs—before code reaches review. - This allows human reviewers to focus on complex issues such as reachability, exploitability, and architectural risk. ## Automated Triage and Governed Remediation - AI should reduce the volume of findings developers must investigate by assessing: - False positives - Reachability - Exploitability - Severity - AI-generated fixes should not bypass normal governance. - Remediation proposals should be submitted as merge requests, with: - Required scans - Policy enforcement - Human approvals - Confidence scores - Complete audit records - Human and AI-authored changes should follow the same review and compliance process. ## Example: Responding to an Emerging Vulnerability - A proof-of-concept exploit may appear before a CVE, NVD entry, or scanner signature exists. - A security agent can inspect dependency graphs across projects, identify affected versions and call paths, and rank production exposure. - Teams can then launch a coordinated remediation campaign: - Upgrade dependencies where patches exist. - Apply targeted code changes where they do not. - Block merge requests that retain the vulnerable dependency. - Require security approval for fixes. - Pipeline tests can reject faulty AI-generated patches, allowing the agent to revise them before developers approve the corrected version. - Automatically collected scan results, policies, approvals, and merge timestamps provide audit evidence without manual reconstruction. ## Strengthen the Pipeline Before Attackers Catch Up - Organizations should verify that security scans run on every merge request, not only in selected projects. - Pipelines should detect compromised or vulnerable dependencies before build time. - Critical findings should move quickly from detection to the responsible developer without unnecessary tool boundaries. - The central recommendation is to make pipeline enforcement, AI-assisted triage, and governed remediation standard parts of the software supply chain before comparable offensive AI capabilities become widely available.

Read original(opens in new tab)
gitlab2 min readCurated summary

Automate remediation with ready-to-merge AI code fixes

GitLab 18.11 makes Agentic SAST Vulnerability Resolution generally available, using AI to analyze vulnerabilities, generate code fixes, test them, and open ready-to-merge merge requests. The release aims to reduce developer context switching and AppSec triage while addressing vulnerabilities before production. It also adds faster scanning, risk-based prioritization, and stronger security governance. ## Automated Remediation in the Developer Workflow - Confirmed SAST true positives automatically enter GitLab Duo Agent Platform’s remediation flow. - The agent: - Analyzes the vulnerability in context. - Generates a root-cause fix. - Validates the change with automated tests. - Developers receive a ready-to-merge MR with a confidence score. - Incremental scanning for Advanced SAST provides results before a complete scan finishes. - The approach addresses the growing remediation burden as AI-generated code increases vulnerability volume. ## Prioritizing Vulnerabilities by Business Risk - Vulnerability scoring now uses CVSS 4.0 for more detailed exploitability assessment. - Policy-based severity overrides can use: - CVE information. - CWE classifications. - File paths and directories. - Approval policies can block or warn on merges based on: - Known Exploited Vulnerabilities (KEV). - EPSS score thresholds. - The Top CWEs dashboard chart helps teams identify recurring vulnerability classes and address systemic causes. ## Security Controls and Scanner Coverage - The new Security Manager role gives security teams permissions to: - Enforce scanners. - Configure security policies. - Manage triage and remediation. - Maintain compliance frameworks and audit streams. - The role excludes code modification and deployment permissions, keeping access appropriately scoped. - SAST configuration profiles allow teams to define scanning centrally and apply it across group projects without maintaining project-level YAML or relying on developers for configuration. GitLab 18.11 combines agentic remediation, faster and more risk-aware scanning, and centralized governance. Organizations seeking to reduce vulnerability backlogs can use these capabilities to automate routine fixes while preserving developer oversight through merge requests and confidence scores.

Read original(opens in new tab)
aws3 min readCurated summary

AWS Weekly Roundup: AWS DevOps Agent & Security Agent GA, Product Lifecycle updates, and more (April 6, 2026) | Amazon Web Services

The April 6, 2026 AWS Weekly Roundup highlights the general availability of AWS DevOps Agent and AWS Security Agent, autonomous “frontier agents” designed to handle complex operational and security tasks. It also reviews AWS service lifecycle changes and summarizes notable product launches and technical updates from the previous week. The overall message is that AWS is expanding agentic automation while helping customers manage service transitions and adopt new capabilities. ## AWS DevOps Agent and Security Agent Reach GA - **AWS DevOps Agent** - Investigates incidents, accelerates resolution, and helps prevent recurring problems. - Works continuously across multiple steps until an operational goal is complete. - Customers report up to **75% lower mean time to resolution (MTTR)** and **3–5 times faster incident resolution**. - Western Governors University reduced resolution times from hours to minutes. - **AWS Security Agent** - Provides continuous, context-aware penetration testing during the software development lifecycle. - Operates similarly to a human penetration tester. - LG CNS reported testing that was more than **50% faster**, approximately **30% less expensive**, and produced fewer false positives. - **Deployment flexibility** - Both agents support AWS, multicloud, and on-premises environments. - They are intended to automate repetitive investigative and testing work while allowing teams to focus on higher-value activities. ## AWS Service Lifecycle Changes AWS updated its Product Lifecycle Changes guidance on March 31, 2026, including migration recommendations and alternative services. - Services with availability changes or maintenance guidance include: - AWS App Runner - AWS Audit Manager - AWS CloudTrail Lake - AWS Glue Ray jobs - AWS IoT FleetWise - Amazon Application Recovery Controller Readiness Check - Amazon Comprehend features such as Topic Modeling and Prompt Safety Classification - Amazon Rekognition streaming and batch moderation features - Amazon SNS Message Data Protection - Services listed as entering sunset include: - AWS Service Management Connector - Amazon RDS Custom for Oracle - Amazon WorkMail - Amazon WorkSpaces Thin Client - **Amazon Chime SDK Proxy Sessions** is reaching sunset. AWS recommends reviewing the relevant service documentation or contacting Support to reduce operational disruption. ## Notable AWS Launches - Amazon ECS introduced **Managed Daemons for ECS Managed Instances**. - The AWS Sustainability console now consolidates **Scope 1–3 emissions reporting**. - **Amazon Bedrock AgentCore Evaluations** became generally available. - AWS Transform added generally available automated codebase analysis. - CloudWatch introduced OpenTelemetry Container Insights for Amazon EKS in preview. - Amazon Lightsail added compute-optimized bundles with up to **72 vCPUs**. - Amazon CloudFront added **SHA-256 support** for signed URLs and signed cookies. ## Additional AWS Resources The roundup also points readers to material on: - Architecting agentic AI applications on AWS. - Reducing data-transfer costs with Network Load Balancers. - Preventing hallucinations in production AI agents. - The AWS World Sports Innovation Cup. - Exploring AWS communities through an interactive 3D globe. AWS also encourages readers to participate in Builder Center discussions, community events, AWS Summits, and developer-focused programs. AWS teams should review the lifecycle notices for services they depend on, while developers and operations groups may benefit from evaluating the new agents and launches for automation, security testing, and observability improvements.

Read original(opens in new tab)
stripe2 min readCurated summary

How Stripe Radar helps prevent free trial abuse

Free trial abuse is accelerating, particularly among AI companies whose trials provide access to costly compute resources. Stripe detected 6.2 times more abusive trials between November 2025 and February 2026, with self-serve AI startups facing especially high exposure. Stripe argues that AI-powered fraud detection can identify abuse at signup and prevent substantial downstream losses. ## The rise of free trial abuse - Fraudsters increasingly cycle through free trials or use invalid payment methods without converting to paid plans. - AI companies are especially vulnerable because free trials can grant access to expensive compute and APIs. - AI startups with self-serve signup and direct API access experience 10 times more attempted abuse than enterprise AI companies. - Similar patterns affect SaaS companies, marketplaces, and other businesses offering free trials. ## Stripe Radar’s abuse-prevention controls - Stripe Radar now offers a one-click control to detect behavior violating common trial terms, including repeated signups and missed cancellations. - The system predicts abusive behavior with 90% accuracy. - A new analytics page displays blocked high-risk payments and, for unenrolled businesses, shows transactions that would have been blocked. - The model analyzes payment instruments, devices, payment history, card BIN data, virtual card indicators, email domains, session timing, and other risk signals across Stripe’s network. ## Results for AI companies - Cursor and other AI businesses use Radar to block suspicious users before they consume costly compute. - Within two months, Stripe blocked over 550,000 high-risk free trials across four high-growth AI companies. - Stripe estimates this prevented $4.4 million in downstream compute-related losses. Stripe recommends its free trial abuse control for businesses across industries. Companies interested in early access can contact Stripe directly.

Read original(opens in new tab)
gitlab3 min readCurated summary

A complete guide to GitLab Container Scanning

GitLab provides multiple container-scanning methods to detect vulnerabilities throughout the container lifecycle, from CI builds to registry monitoring. The guide emphasizes scanning early to identify risks in base images, operating-system packages, and application dependencies before they reach production. It covers pipeline-based scanning in detail and introduces registry scanning for continuously monitoring published images. ## Why Container Scanning Matters - Container vulnerabilities can arise during image creation or while containers are running in production. - Base images, OS packages, and application dependencies may contain exploitable flaws. - Scanning supports a shift-left security strategy by detecting issues before deployment. - Container scanning is part of Software Composition Analysis (SCA), helping teams understand and secure external dependencies. ## Pipeline-Based Container Scanning Pipeline-based scanning analyzes container images during CI/CD execution. - **Purpose:** Detect vulnerabilities before deployment and help prevent unsafe images from reaching production. - **Scanner:** GitLab uses Trivy to identify known vulnerabilities. - **Availability:** Free, Premium, and Ultimate tiers, with additional features in Ultimate. - **Automatic setup:** Use **Secure > Security configuration** and configure Container Scanning through a generated merge request. - **Manual setup:** Include the following template in `.gitlab-ci.yml`: ```yaml include: - template: Jobs/Container-Scanning.gitlab-ci.yml ``` ### Common Configuration Options - Scan a specific image by overriding `CS_IMAGE`: ```yaml include: - template: Jobs/Container-Scanning.gitlab-ci.yml container_scanning: variables: CS_IMAGE: myregistry.com/myapp:latest ``` - Restrict findings to a severity threshold with `CS_SEVERITY_THRESHOLD`: ```yaml container_scanning: variables: CS_SEVERITY_THRESHOLD: "HIGH" ``` This example reports only High and Critical vulnerabilities. ### Merge Request Integration - Findings appear in the merge request’s **Security Scanning** section. - Developers can review newly introduced and existing vulnerabilities during code review. - Each finding includes severity, affected packages, and remediation guidance. - This integrates container security into the development workflow instead of treating it as a separate post-deployment gate. ### Vulnerability Report The centralized Vulnerability Report is available under **Security & Compliance > Vulnerability Report**. - Aggregates container vulnerabilities across project branches. - Supports filtering by severity, status, scanner type, and container image. - Vulnerabilities can be assigned to team members and marked as detected, confirmed, resolved, or dismissed. - Teams can add comments and link related issues to track remediation. - Details show the affected images and layers, helping identify the source of a vulnerability. ### Dependency List and SBOM GitLab’s Dependency List provides a software bill of materials for container images. - Lists packages, libraries, and dependencies detected by Container Scanning. - Shows both base operating-system packages and application dependencies. - Supports filtering by package manager, license type, and vulnerability status. - Connects dependencies with their vulnerabilities for security and compliance analysis. ## Container Scanning for the Registry Registry scanning automatically analyzes images pushed to GitLab’s Container Registry with the `latest` tag. - **Purpose:** Continuously monitor registry images without requiring manual pipeline triggers. - **Availability:** Ultimate tier only. - **Trigger:** GitLab’s security policy bot scans `latest` images against the default branch. - **Continuous monitoring:** Works with Continuous Vulnerability Scanning to detect newly disclosed vulnerabilities. ### Enabling Registry Scanning - Go to **Secure > Security configuration**. - Find **Container Scanning for Registry**. - Toggle the feature on. ### Prerequisites - The user must have the Maintainer role or higher. - The project must contain at least one commit on its default branch. - Container Registry notifications must be configured. - The Package Metadata Database must be configured; it is enabled by default on GitLab.com. GitLab’s scanning options support both preventive CI/CD checks and ongoing registry monitoring. Teams should use pipeline-based scanning to catch vulnerabilities before deployment and registry scanning when they need continuous visibility into published images.

Read original(opens in new tab)
gitlab2 min readCurated summary

Passkeys now available for passwordless sign-in and 2FA on GitLab

GitLab now supports passkeys for passwordless sign-in and phishing-resistant two-factor authentication. Built on WebAuthn and public-key cryptography, passkeys let users authenticate with a fingerprint, face recognition, or device PIN while keeping the private key on their device. Users can register multiple passkeys across browsers, mobile devices, and FIDO2 security keys, improving both security and convenience. ## Passkeys for Sign-In and 2FA - Passkeys can be used: - As a passwordless login method. - As a phishing-resistant 2FA method. - For accounts with 2FA enabled, passkeys automatically become the default 2FA option. - Authentication uses a device fingerprint, facial recognition, or PIN. ## Registration and Compatibility - Users can register passkeys under **Profile settings > Account > Manage authentication**. - Supported platforms include: - Chrome, Firefox, Safari, and Edge. - iOS 16 and later. - Android 9 and later. - FIDO2 hardware security keys. - Multiple passkeys can be registered for access across different devices. ## WebAuthn Security Model - Passkeys rely on WebAuthn and public-key cryptography. - The private key remains securely stored on the user’s device and is never sent to GitLab. - GitLab stores only the public key. - A breach of GitLab’s stored credentials would not give attackers usable private keys for account access. ## GitLab’s Security Goals - Passkeys support GitLab’s commitment under the CISA Secure by Design Pledge. - They help increase MFA adoption while providing a smoother, phishing-resistant authentication experience. - GitLab invites users to provide feedback through its community and feedback channels. Users should register passkeys in their GitLab authentication settings, ideally across multiple trusted devices or security keys for both stronger protection and account recovery.

Read original(opens in new tab)
gitlabOriginal article

How to set up GitLab SAML SSO with Google Workspace (opens in new tab)

Organizations using GitLab.com SaaS can streamline access control by integrating SAML-based Single Sign-On (SSO) with Google Workspace. This setup enables automated user provisioning and dynamic permission management by mapping Google Workspace groups directly to GitLab roles. The result is a centralized security model that reduces manual administrative tasks while ensuring users have immediate, secure access to the platform. ### Prerequisites and Architectural Benefits * The integration requires a GitLab Premium or Ultimate subscription and Super Admin access to Google Workspace. * Once configured, the authentication flow redirects users to Google for credentials, after which Google sends a SAML assertion to GitLab containing user details and group memberships. * The system supports "Just-in-Time" provisioning, meaning GitLab accounts are created automatically upon a user's first successful login. * Permissions are dynamic; GitLab updates group memberships and roles every time a user signs in to reflect their current status in Google Workspace. ### Gathering GitLab Configuration Details * Configuration must be performed at the GitLab top-level group rather than within individual subgroups. * Administrators need to retrieve the Assertion Consumer Service (ACS) URL, which typically follows the format `https://gitlab.com/groups/[your-group]/-/saml/callback`. * The Identifier (Entity ID) must be copied to uniquely identify the GitLab group within the Google identity provider settings. * The GitLab SSO URL is the specific entry point users will utilize to initiate the authentication process. ### Configuring the Google Workspace SAML Application * Within the Google Admin Console, administrators must create a "Custom SAML app" to house the integration settings. * The setup process provides a Google SSO URL and a certificate file (typically a `.pem` format) that must be saved for the GitLab-side configuration. * The previously gathered GitLab ACS URL and Entity ID are entered into the Service Provider details section of the Google app configuration. ### Mapping User Attributes and Synchronizing Groups * Specific attribute mapping is required to ensure user data flows correctly: Google’s "Primary Email" should map to the "NameID," "First Name" to "firstName," and "Last Name" to "lastName." * For group synchronization to function, administrators must map selected Google Groups to an app attribute named exactly `groups` (lowercase). * Google allows for the synchronization of up to 75 groups, which GitLab uses to determine and update user permissions upon login. * The application must be explicitly turned "ON" for specific organizational units or the entire domain within the Google Admin Console to allow user access. ### Finalizing the Identity Provider Connection * GitLab requires a SHA-1 certificate fingerprint for security verification rather than the raw certificate file provided by Google. * Administrators must convert the downloaded Google `.pem` certificate into a SHA-1 fingerprint using an online conversion tool or a command-line utility. * This fingerprint, along with the Google SSO URL, is entered into GitLab’s SAML SSO settings to establish the trusted connection between the two platforms. To ensure a smooth rollout, it is recommended to test the integration with a small group of users before enforcing SAML for the entire organization. This allows administrators to verify that group-based permissions are mapping correctly to GitLab roles without disrupting existing workflows.

woowahanOriginal article

Delivering the Future: Global Hackathon (opens in new tab)

The Global Hackathon 2025 served as a massive collaborative initiative to unite over 270 technical employees from seven global entities under DeliveryHero’s umbrella, including Woowa Brothers. By leveraging the community-building expertise of the Woowahan DevRel team, the event successfully bridged geographical and technical gaps to foster innovation in "Delivering the Future." The hackathon concluded with high-level recognition from global leadership and a strategic partnership with Google Cloud, demonstrating the power of synchronized global technical synergy. ## Strategic Planning and Global Coordination * The event adopted a hybrid "Base Camp" model, where participants worked from their local entity offices while staying connected through 24-hour live streaming and centralized online channels. * Organizers meticulously navigated the logistical hurdles of spanning 70 countries, including coordinating across vastly different time zones and respecting local public holidays and vacation seasons. * Efficiency was maintained through a decentralized communication strategy, using entity-specific meetings and comprehensive guidebooks rather than frequent global meetings to prevent "meeting fatigue" across time zones. ## Technical Infrastructure and Regulatory Compliance * To accommodate diverse technical preferences, the infrastructure had to support various stacks, including AWS, Google Cloud Platform (GCP), and specific machine learning models. * The central organization team addressed complex regulatory challenges, ensuring all sandbox environments complied with strict global security standards and GDPR (EU General Data Protection Regulation). * A strategic partnership with Google Cloud provided a standardized Google AI-based environment, enabling teams to experiment rapidly with mature tools and cloud-native services. ## Local Operations and Cross-Entity Collaboration * Physical office spaces were transformed into immersive hackathon hubs to maintain the high-intensity atmosphere characteristic of offline coding marathons. * The event encouraged "office sharing" between entities located in the same city and even supported travel for members to join different regional base camps, fostering a truly global networking culture. * Local supporters used standardized checklists and operational frameworks to ensure a consistent experience for participants, whether they were in Seoul, Berlin, or Dubai. Building a successful global technical event requires a delicate balance between centralized infrastructure and local autonomy. For organizations operating across multiple regions, investing in shared technical sandboxes and robust communication frameworks is essential for turning fragmented local talent into a unified global innovation engine.

lineOriginal article

Why an Athenz Engineer Took (opens in new tab)

Security platform engineer Jung-woo Kim details his transition from a specialized Athenz developer to a "Kubestronaut," a prestigious CNCF designation awarded to those who master the entire Kubernetes ecosystem. By systematically obtaining five distinct certifications, he argues that deep, practical knowledge of container orchestration is essential for building secure, scalable access control systems in private cloud environments. His journey demonstrates that moving beyond application-level expertise to master cluster administration and security directly improves architectural design and operational troubleshooting. ## The Kubestronaut Framework * The title is awarded by the Cloud Native Computing Foundation (CNCF) to individuals who pass five specific certification exams: CKA, CKAD, CKS, KCNA, and KCSA. * The CKA (Administrator), CKAD (Application Developer), and CKS (Security Specialist) exams are performance-based, requiring candidates to solve real-world technical problems in a live terminal environment rather than answering multiple-choice questions. * Success in these exams demands a combination of deep technical knowledge, speed, and accuracy, as practitioners must configure clusters and resolve failures under strict time constraints. * The remaining Associate-level exams (KCNA and KCSA) provide a theoretical foundation in cloud-native security and ecosystem standards. ## A Progressive Path to Technical Mastery * **CKAD (Application Developer):** The initial focus was on mastering the deployment of Athenz—an open-source auth system—ensuring it runs efficiently from a developer's perspective. Preparation involved rigorous use of tools like killer.sh to simulate high-pressure environments. * **CKA (Administrator):** To manage multi-cluster environments and understand the underlying components that make Kubernetes function, the author moved to the administrator level, gaining insight into how various services interact within the cluster. * **CKS (Security Specialist):** Given his background in security, this was the most critical and difficult stage, focusing on cluster hardening, vulnerability analysis, and implementing strict network policies to ensure the entire infrastructure remains resilient. ## Organizational Impact and Open Source Governance * Obtaining these certifications provided a clearer understanding of open-source governance, specifically how Special Interest Groups (SIGs) and pull request (PR) workflows drive massive projects like Kubernetes. * This technical depth was applied to a high-stakes project providing Athenz services in a Bare Metal as a Service (BMaaS) environment, allowing for more stable and efficient architecture design. * The learning process was supported by corporate initiatives, including access to Udemy Business for technical training and a hybrid work culture that allowed for consistent, early-morning study habits. To achieve expert-level proficiency in complex systems like Kubernetes, engineers should adopt the "Ubo-cheonri" philosophy—making slow but steady progress. Starting with even one minute of study or a single GitHub commit per day can eventually lead to mastering the highest levels of cloud-native architecture. For those managing enterprise-grade infrastructure, pursuing the Kubestronaut path is highly recommended as it transforms theoretical knowledge into a broad, practical vision for system design.

metaOriginal article

Key Transparency Comes to Messenger (opens in new tab)

Messenger has enhanced the security of its end-to-end encrypted chats by launching key transparency, a system that provides an automated, verifiable record of public encryption keys. By moving beyond manual key comparisons, this feature ensures that users can verify their contacts' identities without technical friction, even when those contacts use multiple devices. This implementation allows Messenger to provide a higher level of assurance that no third party, including Meta, has tampered with or swapped the keys used to secure a conversation. ## The Role of Key Transparency in Encrypted Messaging * Provides a verifiable and auditable record of public keys, ensuring that messages are always encrypted with the correct keys for the intended recipient. * Prevents "man-in-the-middle" attacks by a compromised server by making any unauthorized key changes visible to the system. * Simplifies the user experience by automating the verification process, which previously required users to manually compare long strings of characters across every device their contact owned. ## Architecture and Third-Party Auditing * Built upon the open-source Auditable Key Directory (AKD) library, which was previously used to implement similar security properties for WhatsApp. * Partners with Cloudflare to act as a third-party auditor, maintaining a public Key Transparency Dashboard that allows anyone to verify the integrity of the directory. * Leverages an "epoch" system where the directory is updated and published frequently to ensure that the global log of keys remains current and immutable. ## Scaling for Global Messenger Traffic * Manages a massive database that has already grown to billions of entries, reflecting the high volume of users and the fact that Messenger indexes keys for every individual device a user logs into. * Operates at a high frequency, publishing a new epoch approximately every two minutes, with each update containing hundreds of thousands of new key entries. * Optimized the algorithmic efficiency of the AKD library to ensure that cryptographic proof sizes remain small and manageable, even as the number of updates for a single key grows over time. ## Infrastructure Resilience and Recovery * Improved the system's ability to handle temporary outages and long delays in key sequencing, drawing on two years of operational data from the WhatsApp implementation. * Replaced older proof methods that grew linearly with the height of the transparency tree with more efficient operations to maintain high availability and real-time verification speeds. * Established a robust recovery process to ensure that the transparency log remains consistent even after infrastructure disruptions. By automating the verification of encryption keys through a transparent, audited directory, Messenger has made sophisticated cryptographic security accessible to billions of users. This rollout represents a significant shift in how trust is managed in digital communications, replacing manual user checks with a seamless, background-level guarantee of privacy.

datadog3 min readCurated summary

Detecting malicious pull requests at scale with LLMs

Datadog built an LLM-powered security reviewer, BewAIre, to examine every pull request for malicious intent as AI-assisted development increases code volume and reviewer fatigue. Unlike traditional static analysis, the system evaluates the design and likely purpose of changes, not just known syntactic patterns. In testing, it achieved over 99.3% accuracy with a 0.03% false-positive rate and now operates in production. ## Why Conventional Review Is Struggling - Datadog processes nearly 10,000 pull requests per week across internal and external repositories, with volume growing as coding assistants become commonplace. - More changes increase the attack surface and make subtle attacks harder to notice. - Reviewers, linters, and scanners can be overwhelmed by verbose or repetitive AI-generated code. - Static analysis is effective at identifying known bad patterns but generally lacks understanding of developer intent. - Legitimate security-sensitive changes, such as permission-model updates, can resemble malicious behavior. ## The tj-actions/changed-files Attack - An attacker used a compromised personal access token belonging to `tj-actions-bot` to modify `index.js`. - The injected Python code extracted secrets and other sensitive information from a GitHub Actions runner’s process memory. - Base64 encoding concealed both the malicious code reference and output written to build logs. - The commit was made to look like a legitimate `renovate[bot]` update. - Version tags were redirected to the malicious commit, allowing the compromise to spread quickly. - Even protected branches, two-person reviews, and other standard controls could miss an attack disguised as a routine dependency or maintenance change. ## BewAIre’s LLM-Based Review Pipeline - **Ingestion:** Collects pull requests merged into the default branch across Datadog repositories. - **Preprocessing:** Normalizes each pull request, extracts its diff, and adds metadata such as the author and repository type. - **Inference:** Sends the code changes and contextual information to an LLM to reason about intent and classify the change as benign or malicious. - **Security signals:** Converts each verdict into a Datadog security signal that appears in internal dashboards and can trigger alerts or pages for security engineers. - Each finding includes a written explanation of why the change may be malicious. ## Improving Accuracy and Limiting Noise - Datadog used prompt engineering and data tuning to improve the model’s ability to distinguish malicious behavior from legitimate changes. - Suppression rules were added for known-safe patterns. - Testing on a curated, balanced dataset of hundreds of malicious and benign pull requests produced: - More than 99.3% overall accuracy. - More than 93.5% balanced accuracy. - A 0.03% false-positive rate. - The team also designed the system to address model degradation caused by context limits and continuously evaluated it against real-world attacks, including the tj-actions and Nx incidents. ## Production Deployment - BewAIre reviews Datadog pull requests in real time and is already deployed across the company’s repositories. - The system is available in Preview to Static Code Analysis customers. - Its purpose is to add scalable, intent-focused detection without imposing stricter manual review requirements that could slow development. Datadog’s approach suggests that LLMs can complement—not replace—static analysis and human investigation by providing continuous, intent-aware security review at large scale.

Read original(opens in new tab)
lineOriginal article

Hosting the Tech Conference Tech- (opens in new tab)

LY Corporation is hosting its global technology conference, Tech-Verse 2025, on June 30 and July 1 to showcase the engineering expertise of its international teams. The event features 127 sessions centered on core themes of AI and security, offering a deep dive into how the group's developers, designers, and product managers solve large-scale technical challenges. Interested participants can register for free on the official website to access the online live-streamed sessions, which include real-time interpretation in English, Korean, and Japanese. ### Conference Overview and Access * The event runs for two days, from 10:00 AM to 6:00 PM (KST), and is primarily delivered via online streaming. * Registration is open to the public at no cost through the Tech-Verse 2025 official website. * The conference brings together technical talent from across the LY Corporation Group, including LINE Plus, LINE Taiwan, and LINE Vietnam. ### Multi-Disciplinary Technical Tracks * The agenda is divided into 12 distinct categories to cover the full spectrum of software development and product lifecycle. * Day 1 focuses on foundational technologies: AI, Security, Server-side development, Private Cloud, Infrastructure, and Data Platforms. * Day 2 explores application and management layers: AI Use Cases, Frontend, Mobile Applications, Design, Product Management, and Engineering Management. ### Key Engineering Case Studies and Sessions * **AI and Data Automation:** Sessions explore the evolution of development processes using AI, the shift from "Vibe Coding" to professional AI-assisted engineering, and the use of Generative AI to automate data pipelines. * **Infrastructure and Scaling:** Presentations include how the "Central Dogma Control Plane" connects thousands of services within LY Corporation and methods for improving video playback quality for LINE Call. * **Framework Migration:** A featured case study details the strategic transition of the "Demae-can" service from React Native to Flutter. * **Product Insights:** Deep dives into user experience design and data-driven insights gathered from LINE Talk's global user base. Tech-Verse 2025 provides a valuable opportunity for developers to learn from real-world deployments of AI and large-scale infrastructure. Given the breadth of the 127 sessions and the availability of real-time translation, tech professionals should review the timetable in advance to prioritize tracks relevant to their specific engineering interests.

figma3 min readCurated summary

Figma's commitment to FedRAMP | Figma Blog

Figma is pursuing FedRAMP Moderate certification to make its collaborative design platform available to US government agencies and public-sector organizations. The certification process demonstrates that Figma meets rigorous security and privacy requirements and would allow government teams to safely design, prototype, and test digital services. Figma argues that its browser-based, collaborative workflow could help agencies iterate faster and improve citizen-facing software. ## FedRAMP Status and Purpose - Figma’s FedRAMP Moderate authorization is currently “in process.” - Listing on the FedRAMP Marketplace indicates that Figma has completed an audit and is moving through the final certification steps. - FedRAMP evaluates cloud applications against government security controls and categorizes them as low, moderate, or high impact. - Certification is necessary before Figma can fully host government data. ## Benefits for Public-Sector Users - Certification would allow government agencies, contractors, and civic-technology teams to: - Create software designs in Figma - Build and test interactive prototypes - Validate ideas through rapid iteration - Improve the usability of government applications - Figma says the certification will give customers confidence that their data and content meet demanding security and privacy standards. - Its browser-based and platform-agnostic design supports collaboration among distributed teams, including agencies and contingent workers. ## Public-Sector Collaboration and Modernization - The shift toward hybrid and remote work has increased demand for accessible, collaborative digital tools in government. - Figma connects this trend with broader efforts to improve customer experience and rebuild trust in government services. - The company believes public-sector organizations often work similarly to private companies despite having different missions and business models. - Collaborative design could help agencies ship services more quickly and achieve better outcomes for citizens. ## Building a Federal Government Team - Figma is expanding its federal-government organization, beginning with federal sales leader James Kohler. - The company is seeking people who understand government procurement and security requirements while also being able to build new programs from the ground up. - Kohler’s role is to adapt lessons from Figma’s private-sector work to the needs of government users. - Figma plans to encourage knowledge sharing between its commercial and government teams. ## Next Steps - Figma’s immediate goal is to complete FedRAMP certification and become authorized for federal use. - The company intends to continue engaging public-sector customers and sharing updates about its government efforts. Figma’s certification effort is a prerequisite for broader government adoption. If completed, the platform could give public-sector teams a secure way to collaborate on and rapidly improve digital services.

Read original(opens in new tab)