今日已更新 135 条资讯 | 累计 24421 条内容
关于我们

标签:#security

找到 810 篇相关文章

AI 资讯

GHES Key Rotation, Bug Bounty Program Refocus, AI Agent Permission Fatigue

GHES Key Rotation, Bug Bounty Program Refocus, AI Agent Permission Fatigue Today's Highlights This week's top security news features critical action for GitHub Enterprise Server users with a signing key rotation due to an ongoing investigation. We also cover GitHub's strategic refocusing of its bug bounty program for higher quality submissions and an interactive look at AI agent permission fatigue. Investigation update: GitHub Enterprise Server signing key rotation (GitHub Blog) Source: https://github.blog/security/investigating-unauthorized-access-to-githubs-internal-repositories/ This alert details a critical security update for GitHub Enterprise Server (GHES) customers, urging immediate action to rotate signing keys. The blog post indicates an investigation into unauthorized access to GitHub's internal repositories, which has necessitated this widespread security measure. While specific details of the breach or vulnerability are not fully disclosed, the requirement for a signing key rotation points to a potential compromise of cryptographic keys, which are fundamental to authentication and supply chain integrity. Such incidents could lead to unauthorized code signing, repository tampering, or other severe supply chain attacks, underscoring the importance of robust secrets management and incident response protocols. The advisory emphasizes a proactive stance for GHES administrators to protect their environments by following the provided guidance. This incident highlights the pervasive risk of supply chain attacks and the critical role of secure key management in enterprise environments. It reminds organizations that even trusted platforms like GitHub are targets and necessitates vigilant monitoring and swift action in response to security advisories. The prompt action from GitHub, though implying a significant security event, also showcases their commitment to transparency and securing their ecosystem by guiding customers through the necessary remediation steps to

2026-05-29 原文 →
AI 资讯

The New Shape of Supply-Chain Trust

One poisoned extension, one package install, one CI workflow. Any of them can now be the first domino. That is the uncomfortable lesson from the latest Shai-Hulud activity and GitHub’s recently confirmed internal-repository breach. The scary part is not only the number of affected packages, tokens, or repositories. Counts move fast. The scarier part is where the attacker code ran: inside the trusted developer and CI path. The modern supply chain is not just “the dependencies we ship to production.” It is your IDE, your package manager, your GitHub Actions runner, your cache keys, your OIDC flow, your local gh auth, your AI coding tool config, and the cloud account that quietly pays the bill when something goes sideways. What happened, briefly CISA described the original Shai-Hulud wave as a self-replicating npm worm that compromised more than 500 packages and targeted GitHub personal access tokens plus AWS, GCP, and Azure keys. GitHub later said it removed 500+ compromised packages and began pushing npm toward shorter-lived credentials, 2FA enforcement, and trusted publishing. The later waves got more CI-aware. Instead of only stealing npm tokens from maintainers, they looked for credentials inside build environments, abused publishing workflows, and used the build system itself as distribution. Microsoft’s May 2026 reporting on the @antv ecosystem described a “Mini Shai-Hulud” style campaign that targeted GitHub Actions environments and stole GitHub, AWS, Vault, npm, Kubernetes, and 1Password secrets. Microsoft said GitHub removed 640 malicious packages and invalidated 61,274 npm granular access tokens with write permissions and 2FA bypass. Then GitHub confirmed an incident involving a compromised employee device and a poisoned third-party VS Code extension. GitHub said the attacker’s claim of roughly 3,800 internal repositories was “directionally consistent” with its investigation, while also saying its current assessment was exfiltration of GitHub-internal reposi

2026-05-28 原文 →
AI 资讯

Leaked Kubernetes Secrets: Impact Assessment and Mitigation Strategies

Threat-intel reports from recent years document campaigns in which attackers obtain AWS IAM credentials from developer workstations, use them to enumerate cloud accounts and access Kubernetes clusters. From there, attackers deploy poisoned container images to move laterally and harvest secrets. The MITRE ATT&CK chain maps to: T1552.001 ( Credentials in Files ) → T1078.004 ( Valid Accounts: Cloud Accounts ) → T1610 ( Deploy Container ) → T1496 ( Resource Hijacking ). This is not an isolated case. The Shai-Hulud supply chain attack harvested Kubernetes credentials from CI and developer workstations, feeding exactly this kind of attack chain. This research started with a short list of questions: What are Kubernetes secrets, exactly? What can an attacker do with them? How can defenders harden their clusters? So before we look at what we found in the wild, and how to harden clusters to mitigate impacts, let's define what Kubernetes secrets are. Three Surfaces, Three Secret Formats A simplified view of the cluster has three sides that matter for this post: A developer, or automation pipeline, talks to the Kubernetes API server with credentials. That is the canonical front door. On every node, the kubelet exposes its own HTTPS API. The same credentials can authenticate to it directly when it is reachable on the network. The cluster's nodes pull images from container registries (Docker Hub, GitHub Container Registry, ECR, Quay, GitLab, ACR…) using a second set of credentials. Kubernetes Architecture These are the attack surfaces where leaked secrets have the most impact, and three secret formats unlock them: TLS client certificates are used by humans through a kubeconfig file with the kubectl command to connect to a Kubernetes cluster. JSON Web Tokens, or Service Accounts, are non-human identities (NHI) used to automate cluster operations from CI/CD jobs, controllers, and integrations. By default, JWTs have no expiration date — which is why a JWT leaked years ago can still

2026-05-28 原文 →
AI 资讯

Gemini for Google Home can now use your cameras to trigger automations

Google Home is rolling out a new Gemini-powered automation feature that can trigger smart home routines based on what your security cameras can see. This is one of several updates announced yesterday for Gemini for Home, including enhanced voice command support and general stability improvements, following its early access launch in October. "We are introducing […]

2026-05-28 原文 →
AI 资讯

Demystifying WebP to PNG: Secure Serverless Edge Routing Configurations Without Leaking Credentials

Demystifying WebP to PNG: How to Secure Serverless Edge Routing Configurations Safely We have all been there. You are building a high-performance, modern web application and you decide to store all user-generated assets in modern, ultra-compressed WebP formats. It is a smart move for your Google Lighthouse scores. Then, the legacy enterprise integration request hits your inbox. A major client needs to pull these same assets dynamically, but their internal 15-year-old reporting engine only supports PNG. Suddenly, you need to configure a runtime conversion pipeline that handles complex input schemas, transforms formats on the fly, and manages edge routes without exposing your internal database claims or API secrets. Setting up secure serverless edge routing configurations to convert images on-demand can quickly turn into a security nightmare. If you do not handle incoming credential tokens correctly, you risk forwarding sensitive OAuth scopes or database keys directly to downstream image-processing worker nodes. In this guide, we will break down exactly how to architect a lightweight, secure, and fast edge routing pipeline that validates incoming image request schemas and converts WebP to PNG without leaking sensitive backend credentials. The Problem Modern edge runtimes like Cloudflare Workers, Vercel Edge Functions, or AWS CloudFront Functions are incredibly fast, but they have strict execution limits. They run on V8 isolates, meaning you do not have a full Node.js environment with unlimited memory and access to heavy C++ binaries like sharp or canvas without paying a massive cold-start penalty. If you want to support legacy clients by converting WebP to PNG on the fly, you are faced with three major challenges: Bundle Size Restrictions : Edge functions typically restrict your code size to 1MB or 2MB. Bundling heavy native libraries to parse image bytes is a recipe for deployment failures. Credential Leakage : Edge routers often intercept incoming JWT authorization

2026-05-28 原文 →
AI 资讯

Understanding known_hosts and Host Key Verification: What It Protects Against and How TOFU Works

That "authenticity of host can't be established" message isn't just noise. Here's what's actually happening — and why blindly typing "yes" is a security mistake. Every developer has seen this: The authenticity of host 'example.com (203.0.113.1)' can't be established. ED25519 key fingerprint is SHA256:abc123xyz... Are you sure you want to continue connecting (yes/no/[fingerprint])? Almost everyone types yes without reading it. Then they move on. This message is SSH trying to protect you from one of the most dangerous attacks in network security: the man-in-the-middle attack. Understanding what's happening here — and what the ~/.ssh/known_hosts file actually does — will change how you think about every SSH connection you make. The Problem SSH Is Solving When you connect to ssh user@example.com , how do you know you're actually talking to example.com ? You can't rely on the IP address — IP addresses can be spoofed or rerouted. You can't rely on DNS — DNS can be poisoned. You can't rely on the network path — traffic can be intercepted at any point between you and the server. Without verification, an attacker positioned between you and the server could intercept the connection, pose as the server, decrypt everything you send, re-encrypt it, and forward it along. You'd type your password or authenticate with your key and never know the attacker saw every keystroke. This is a man-in-the-middle (MITM) attack . It's not theoretical. It happens on compromised networks, corporate proxies, malicious Wi-Fi hotspots, and misconfigured infrastructure. SSH's defense is host key verification . Every SSH server has a unique cryptographic identity — its host key. Before you exchange any sensitive data, the server proves it holds the private key corresponding to a public key you've previously verified. If the keys don't match, SSH warns you — loudly. What a Host Key Actually Is When OpenSSH is installed on a server, it automatically generates a set of host key pairs. These live in /etc

2026-05-28 原文 →
AI 资讯

Sniffing Modbus Traffic with 5 Lines of Python (And Why It Should Scare Your OT Team)

⚠️ For defensive/educational purposes only. Sniff only networks you own or are explicitly authorized to test. Unauthorized network monitoring is illegal in most jurisdictions. The uncomfortable truth about your factory floor If your plant uses Modbus TCP — and statistically, it probably does — every register read, every coil write, every sensor value is flying across your network in plaintext . No encryption. No authentication. No signature. Nothing. Modbus was designed in 1979 by Modicon for serial communication between a PLC and a few field devices on a dedicated cable. The threat model was "someone might physically tap the wire." The solution was "don't let strangers into the control room." Forty-five years later, that same protocol is running over your corporate VLAN, talking to cloud historians, and occasionally — if your IT/OT segmentation has gaps — reachable from the internet. Let me show you what that looks like from the wire. The 5-line sniffer This is a defensive monitoring tool. Same code your blue team would use to baseline normal traffic and detect anomalies. Requires scapy : pip install scapy from scapy.all import sniff , TCP , Raw def show_modbus ( pkt ): if TCP in pkt and pkt [ TCP ]. dport == 502 and Raw in pkt : payload = pkt [ Raw ]. load print ( f " { pkt [ ' IP ' ]. src } → { pkt [ ' IP ' ]. dst } : { payload . hex () } " ) sniff ( filter = " tcp port 502 " , prn = show_modbus , store = False ) Run it on a span port, a TAP, or a mirror VLAN, and within seconds you'll see something like this: 192.168.1.50 → 192.168.1.10: 0001000000060103006400 02 192.168.1.10 → 192.168.1.50: 00010000000701030441f00000 192.168.1.50 → 192.168.1.10: 00020000000601100065000102 Every byte tells a story. Let's decode the first packet. Decoding what you just captured The Modbus TCP frame format is documented in the spec (it's public — that's part of the problem): Bytes 0-1: Transaction ID Bytes 2-3: Protocol ID (always 0x0000 for Modbus) Bytes 4-5: Length Byte 6: Unit

2026-05-28 原文 →
AI 资讯

The Sovereign Privacy Illusion: Why GDPR Compliance Doesn’t Equal Data Control

When regulation becomes theater and encryption becomes window dressing By Vektor Memory — 20 min read It is raining here in the Southern Hemisphere again. It has been raining for three weeks now, nonstop. I’m sitting with my chai coffee, watching out of the window, and thinking about data sovereignty. It is, genuinely, the kind of thing I think about often. The northern hemisphere is winding up for summer. Europe is getting ready for long evenings and beach holidays. I’m quietly jealous. I’ve always wanted to split the year: six months south, six months north. Endless summer. The perpetual warmth of a life lived chasing the sun. But here I am. Chai. Rain. Data. I’ve been turning over one question in particular: why is it that the moment you mention data sovereignty, people immediately reach for GDPR? It’s reflexive, especially among Europeans. Understandable. GDPR is loud, it’s enforced, it has teeth. French, German, and Dutch visitors make up a large disproportionate share of our site traffic at VEKTOR, and the interest in privacy and sovereignty from that audience is intense and genuine. Northern Europeans, by and large, take this seriously in a way that other markets don’t; they are working on ways to disassociate from the cloud around the world. And yet. How many times have we clicked “Accept All” on a cookie banner in the last week? How many times have you scrolled past a privacy policy that runs to forty-two pages? How many times have you handed over your email address, your location, your device fingerprint, your behavioral patterns not because you wanted to, but because there was no meaningful alternative? GDPR created the most sophisticated legal architecture for data rights the world has ever seen. It also created the most sophisticated ritual of consent theater the world has ever performed. That gap, between the law and the lived reality, is what this article is about. Ubiquitous data centre growth image The Reflex Problem When people think of data sovere

2026-05-28 原文 →