Angreifer nehmen seit einigen Wochen Gitlab-Server ins Visier. Fast jede dritte Gitlab-Instanz ist anfällig für mindestens eine kritische Sicherheitslücke. (Sicherheitslücke, Ruby)
Quelle: Golem
Mit Ginux will der Gründer von CentOS und Rocky Linux zeigen, dass von Menschen dirigierte KI Entwicklungsarbeit deutlich beschleunigen kann. (KI, CentOS)
Quelle: Golem
Weil vor 2040 kein Ersatz für Hubble im Orbit sein wird, soll das Weltraumteleskop wieder angehoben werden. Unklar ist, wer das kann. (Weltraumteleskop, Nasa)
Quelle: Golem
Millions of people rely on the cloud every day, yet researchers working to secure and improve the cloud are often locked out of the technology it runs on. Jeffery Lim is trying to change that.One such technology, single-root input/output virtualization (SR-IOV), lets major cloud providers like Amazon Web Services boost the performance of their systems. Cloud providers combine SR-IOV with custom hardware and software to deliver faster cloud services than traditional setups allow.Lim is a computer engineer at MIT Lincoln Laboratory. While pursuing his master’s degree, he noticed that academic research proposing smarter or safer cloud infrastructure did not account for SR-IOV. Very few open-source hardware platforms existed that would let researchers work directly with SR-IOV as they developed new software or models to improve the cloud.So, Lim filled that gap with his master’s thesis, building a hardware platform compatible with SR-IOV that captures key features of the infrastructure used by cloud providers. The result is a research and development platform that allows researchers to build, test, and evaluate realistic cloud designs.”As a society, everyone uses the cloud now,” Lim says. “I hope that people will use this platform to build systems more akin to how cloud providers operate, and, more broadly, that researchers everywhere can take advantage of SR-IOV for the performance benefits it offers.”Lim presented a paper at the IEEE High-Performance Extreme Computing Conference in September, and he plans to release this work open source. In recognition of the hardware’s potential impact, the Boston University College of Engineering awarded Lim its 2026 Master’s Societal Impact Award.Winding path to cybersecurityGrowing up, Lim was fascinated with building computers. That fascination set him on a winding path to the Secure Resilient Systems and Technology Group at Lincoln Laboratory.After studying electrical and computer engineering at the University of Colorado at Boulder, he spent several years in industry working on field-programmable gate arrays (FPGAs) — integrated circuits that can be repeatedly reprogrammed for different functions. This background led to his 2018 hire at the laboratory, where he developed FPGAs for small radars that detect the breathing of humans trapped in rubble and for large radars that track satellites and orbital debris from atop Millstone Hill. He next turned to investigating radiation-induced faults in integrated circuits aboard space platforms and ways to protect the chips.This focus on safeguarding hardware turned his attention to cybersecurity, an area he had long found interest in but never fully explored. So, Lim transferred to his current group in 2022 to pursue this interest.”I don’t think there’s another place in the world where I could say, ‘Hey, I want to try something new,’ and actually have that opportunity,” Lim says. “Lincoln Laboratory does that really well, giving people the chance to transition into a different field of engineering or area of expertise.”To deepen his expertise, he applied and was accepted in 2024 to the Lincoln Scholars Program, which allows technical staff to pursue full-time graduate studies at the master’s or doctoral level. Scholars remain employed and apply their academic work to national security needs.As he pursued his master’s degree at Boston University, Lim worked closely with his Lincoln Laboratory mentor Benjamin Nahill, who helped Lim keep his research tied to the laboratory’s mission and provided a sounding board for ideas. “I’d call him my rubber ducky,” Lim says, a nod to the classic software engineering practice of “rubber duck debugging” — reasoning things out through speaking aloud to a rubber duck.”We talked about his thesis concept for quite a while, but the implementation suddenly became real toward the end,” says Nahill. “He transformed what began as an idea for a research tool to an incredibly performant implementation. Having worked with Jeffery on projects in our group, I shouldn’t have been surprised, but it was most impressive.”Missing piece for cloud researchWhen most people say “the cloud,” they mean cloud services provided by companies such as Amazon, Microsoft, and Google. Virtualization is the invisible process that makes those services possible. Users uploading photos or streaming movies are interacting with virtual machines, running on servers in data centers.In the past decade, SR-IOV has changed the way traditional virtualization works. Traditionally, a software component known as the hypervisor acts as a middleman between the virtual machines and the server’s physical hardware. Its main role is to distribute computing resources as needed, and provide functions (such as networking) to the virtual machines.In contrast, SR-IOV enables virtual machines to access a dedicated slice of the hardware device, reducing the hypervisor overhead. This capability is often found on specialized devices called Smart Network Interface Cards (SmartNICs). Major cloud platforms, such as Amazon Web Services’ Nitro System and Microsoft’s Azure Accelerated Networking, use SmartNICs with SR-IOV to provide high-speed networking to many virtual machines.”This was the missing research capability that I set out to build: an open-source SmartNIC platform compatible with SR-IOV,” Lim says. Because SmartNICs can be built on FPGAs, Lim had a familiar starting point. In fact, he found a couple of platforms that supported SR-IOV; however, they lacked features that would make them practical tools for researchers to utilize. He spent a couple of months building those required components.The first component is a switching fabric. Often, cloud customers’ applications or programs may be split across multiple virtual machines, which may be distributed across multiple servers. Therefore, the cloud system needs a way to determine whether a piece of data needs to stay local or leave the server. Lim’s switching fabric handles that traffic-directing job.The second component is a network function engine. This small, specialized processor is built to run security rules, like firewalls, that keep one customer’s data safely separated from another’s. To build it, Lim used Extended Berkeley Packet Filter, a system that allows custom code to inspect network traffic, approving or blocking data as needed. Rather than starting from scratch, he adapted the design from doctoral research conducted by Zaid Tahir, who studied under their shared advisor, Professor Martin Herbordt of Boston University.Herbordt described Lim’s efforts as “combining vision with heroic system-building, single-handedly putting together the hardware and software necessary to prove the concept.””I’m very much a hands-on hardware guy, so, yes, I ended up building two servers at home to test my designs,” Lim says. He also used the Mass Open Cloud’s Open Cloud Testbed, a test bed meant for testing cloud platforms, to gather metrics and validate his system.Impact beyond the platformThroughout the project, Lim maintained focus on applicability and transparency. “My biggest worry was, is this going to be relevant? Is this something that can actually be utilized?” Lim reflects. Earning the Societal Impact Award points to yes. The award recognizes projects that address pressing global challenges through innovative applications of technology. Lim’s platform opens the door to evaluating a cloud trust model that remains largely opaque, even as many sectors of society, from health care to banking, increasingly rely on it.”Right now, we have limited visibility into how major cloud providers implement and evolve their infrastructure,” Lim says. “If researchers can catch up to how the modern cloud operates, they might develop new approaches that improve security or performance.”As part of his role as a Lincoln Scholar, Lim is also exploring how his work connects to Lincoln Laboratory’s national security mission. He sees several potential avenues.One program in his group is evaluating cyber-hardening techniques for hypervisors, as the cloud takes on an expanding role in defense systems. “Introducing Lim’s SR-IOV-compatible platform to this work would help bring our research closer to how cloud environments operate, demonstrating the impact of our techniques in realistic environments,” says Nathan Burow, the program’s principal investigator. Another program is examining what it takes to stand up high-performance data centers, work that could draw directly on Lim’s research into the technologies SR-IOV requires.Or his path may lead to something new. The laboratory allocates internal technical investment funding — supported by the Office of the Under Secretary of War for Research and Development — for staff-proposed projects addressing emerging needs. Lim is considering a proposal to bring SR-IOV to the embedded-systems level, say, to drones or satellites.”We saw how cloud providers moved from traditional virtualization to SR-IOV to maximize performance while maintaining isolation,” he says. “I wonder if we can do the same at the embedded level, where power and compute constraints are even tighter. I’d love to complete that transition. I learned a lot from the cloud. Now, can we apply those lessons somewhere else?”
Quelle: Massachusetts Institute of Technology
In 2025, the average global Fortune 500 enterprise had fewer than 15 AI agents in use. Gartner expects that number to explode to more than 150,000 by 2028. Only 13 percent of organizations think they have the right governance for today, and AI is evolving and moving faster than any other technology paradigm in our history.
Today, most security leaders face an agentic Sophie’s choice: allow AI adoption without the right controls and hope for the best, or block it and become the obstacle to a priority the business has already set (while adoption continues in the shadows, anyway).
But there is a third option, one in which organizations fully tap into the transformative power of agentic agents without having to live in fear of a catastrophic security failure. The good news is history has already shown how to get there.
How technology gets adopted
Historically, technology adoption has followed a reliable pattern. A capability spreads, each vendor and team builds its own approach, the inconsistency becomes expensive and ineffective, leading the industry to agree to a shared baseline. Adoption then accelerates.
Take the credit card industry, for example. The big credit brands each ran their own security programs, and merchants had to satisfy every one. This was, of course, cumbersome for the vendors, but also for the customers, too. Every time a customer wanted to adopt a new technology, they had to manually build out security and adoption plans, adding significant adoption and procurement delays.
Rather than continue on their own, the credit card companies came together to create PCI DSS 1.0 in December 2004 and formed the PCI Security Standards Council in 2006. Buyers now had one thing to ask for, and auditors had one thing to check. Collaboration overcame complexity, and everyone benefited.
Security-minded technologists can find another example closer to home in the Center for Internet Security (CIS). In the early days of the internet, cybersecurity was a veritable wild west. Enter the CIS, which was founded in 2000 because the industry lacked prescriptive, recognized hardening standards. To this day, each CIS Benchmark is built by consensus among volunteer experts, vendors, and academics.
Docker itself is no stranger to the development and furthering of shared standards. As just one example, in 2015, Docker contributed its image format and runC runtime to the Open Container Initiative. A shared baseline at the runtime layer let registries, runtimes, and clouds interoperate.
Each of these examples played a different role: PCI mandated, CIS guided, and OCI standardized.
Agents will need elements of all three.
Where enterprise AI is on that curve
Agents are in the everyone-builds-their-own phase. Each product solves a real piece of the problem, but which piece, and how the pieces fit, is rarely clear. “Agent governance” or even “AI governance” can mean almost anything.
Adoption is incremental. A developer allows common commands, widens filesystem access, then connects GitHub, a cloud tool and an MCP server, each through a prompt that makes sense on its own. The logs mostly record that the developer acted. Security is often the last to know.
The risks: familiar and new
Much of the risk is familiar. Shadow adoption looks a lot like early SaaS and cloud. Credential sprawl and supply chain exposure are old problems. Inventory, least privilege, audit, and joiner-mover-leaver discipline still apply.
Several things are new, however:
Runtime reprogramming. Users — and the agents themselves — can change what an agent does in plain language, with no release cycle.
Borrowed identity. An agent typically assumes the user’s identity, so anything the user can read, change, or delete, the agent can too.
Autonomy. Agents act asynchronously, spawn sub-agents, and pass authority down the chain. A bad instruction can become an action before anyone steps in.
Risky combinations. A tool with no known vulnerability can still complete a path from untrusted input to sensitive data to external communication.
A shorter response window. Containment has to revoke credentials and sessions, not only kill a process.
Existing controls still matter, but they were not built for this mix of programmability, access, and autonomy.
How the Blueprint Alliance and Agent Baseline respond
As with the credit industry and PCI, cybersecurity and the CIS, and containerization and OCI, collaboration offers the answer to this new era of complexity. That’s why Docker is not just focused on building tools like Docker Sandboxes and Docker AI Governance, but in taking an ecosystem-centric approach to problem solving for our customers. Docker is already a founding participant in multiple initiatives aimed at developing valuable reference architectures for AI security workflows, including the Blueprint Alliance and Agent Baseline.
Both start from the same premise: no single vendor or enforcement point can solve this.
The Blueprint Alliance sets out how the pieces fit together. Okta, AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz and Zscaler are founding members, with GE Appliances and World Central Kitchen as strategic advisors. The open, multi-vendor reference architecture answers four questions: Where are my agents? What can they do? What are they doing? How do I respond? Members have committed to interoperability testing over MCP, OCSF, SSF and CAEP, and to publishing reference integrations.
Agent Baseline sets out what each piece must do and how to verify it. It fills the gap between threat lists, which say what can go wrong, and the capabilities an enterprise needs in place. It defines six outcomes (Discover, Constrain, Authorize, Observe, Validate and Respond) and 35 open, versioned controls, each with a permanent identifier you can cite in an audit finding or RFP response. Docker, Snyk and Keycard drafted it, and the current release is v1.0-draft. Controls stay where they already live, in the identity provider, the sandbox and the SIEM.
Blueprint says how the pieces connect. Agent Baseline says what must be true and can be checked. Both advise starting with discovery before policy, and testing the kill switch before you need it.
For partners, the roles are defined. The Alliance whitepaper assigns integrators the operating model: assessing a customer’s current stack against the architecture, assigning ownership across the pillars, tiering risk, and running lifecycle and compliance over time. Technology partners get a published target to integrate against, and the reference integrations cross vendor lines by design. The partners who can design, integrate and operate across those lines are the ones customers keep.
Where Docker fits
Most Alliance members govern agents from the outside: who the agent is, what it can reach, and what it is observed doing. Docker governs the inside: the environment where the agent executes. As agents move from suggesting actions to taking them, trust has to extend beyond the model to the places where they run. Docker has helped define a shared baseline for the runtime before, and now we’re working with the Alliance and our partners to make that baseline concrete, open, and testable in the age of agents.
The execution environment is where policy gets enforced and evidence gets produced.
That boundary is where policy gets enforced and evidence gets produced. The Alliance whitepaper notes that without runtime support to pause an agent without collateral impact, API-driven containment “provides a false sense of security.” Agent Baseline’s CON-03 calls for isolated, confined execution, which is the job of Docker Sandboxes, while Docker MCP Gateway and Docker Hardened Images cover tool access and the supply chain.The Secure Software Factory reference architecture, drafted in part by Docker authors, applies Agent Baseline to agents that ship code.
What to do next
Baselines let adoption move faster, not slower. Security and platform leaders can assess against the baseline today. Agent Baseline controls are citable, and Okta offers an AI Blueprint Assessment Tool. Partners can start with the Docker Navigator Partner Program, which rewards AI governance work, and with the reference integrations the Alliance publishes. Docker’s VP of Partners Leon Jones explains the program here. Download the blueprint at blueprintalliance.ai and read the controls at agentbaseline.org.
Quelle: https://blog.docker.com/feed/
Giving an agent a sandbox also means deciding which files it will work on. You can share a checkout from your host, give it a separate working directory for a task, or keep the repository entirely inside the sandbox. Each arrangement changes how you, the human, participate in the work.
You might want to watch the diff in your local editor and make changes alongside the agent, or give it room to manage several tasks while you review the results. sbx supports both. The way you organize the checkout can change as you ask the agent to take on more of the work.
Mounting a repository from your host
Sharing a checkout puts the agent in the working tree you already use. Run sbx run from your project directory, and it mounts that directory at the same absolute path inside the sandbox:
$ cd ~/my-project
$ sbx run claude
Open a file in your local editor while the agent works on it, and you’ll see changes as they happen. Git works from either side, so you choose whether you want to let the agent make commits or you do it yourself. Development servers on your host can pick up the edits through hot reload, using the runtime and dependencies installed on your host.
This fits close collaboration on one task. The coordination cost comes from sharing that working tree: switching branches changes the files the agent sees, and your edits become part of its ongoing work. If you want to switch to something unrelated while the agent continues, you’ll need another checkout.
[!NOTE] Dependencies written into the shared checkout are shared too. Packages with native binaries, such as esbuild, may work in the Linux sandbox and fail on a macOS or Windows host. Reinstalling on the host can reverse the problem. Keep separate dependency installations, or run the app consistently in one environment.
Give each task a separate working tree
Git worktrees give each task a directory and branch. You can mount each worktree in its own sandbox, while your original checkout remains available for other work. The agent’s edits appear in the worktree. You can inspect either with your local editor and development tools. Each task also gets its own running environment, with tools to prepare and a sandbox and worktree to clean up afterward.
There is a Git limitation with mounting only a linked worktree. Its .git file points to metadata outside the mount, which the agent can’t reach. It can edit files, but checking status, branching, and committing have to happen on the host. The future of software development still needs you to run git status.
sbx supports a clone mode that gives the agent a separate checkout with Git available inside the sandbox. You keep your local project, but sbx mounts the host source as read-only and creates an independent clone for the agent. Its branch changes and dependency installations stay in its checkout.
Bringing the result back becomes a handoff. While the sandbox is running, you can fetch committed branches through the Git remote sbx adds on your host. Or the agent can push to the repository’s remote and you can retrieve the branch through your usual Git workflow. Your local editor and development server see the changes after you bring them into your checkout.
Keep the project inside the sandbox
A mountless sandbox has no host workspace directory attached. Clone the repository inside it, and the sandbox holds the checkout and its development environment. Your host copy of the project shares no connection with the sandbox checkout.
This workflow resembles working on a remote development machine. Agents connect to the project environment, and you can open a shell with sbx exec or connect an editor to the sandbox over SSH. Changes and dependency installations stay separate from your host. To bring work back, you push a branch to the Git remote.
One sandbox per project can be a useful mental model here. The project and its tools persist across agent sessions and sandbox restarts. An agent can create worktrees per feature it’s working on, push branches, and create pull requests for review. Starting another task doesn’t require you to prepare another host worktree and sandbox, and the agent has Git access in each working directory. Clone mode supports this internal-worktree approach too.
Those tasks share tools and services, so running servers or changing the environment still needs coordination. Separate sandboxes are useful when tasks need independent environments as well as separate files. Branches alone don’t isolate simultaneous edits in one working directory.
That independence adds some distance when you want to try the result. Your usual local editor isn’t looking at these files, and a development server running inside the sandbox needs a published port to reach it from your browser.
For a web app preview, ask the agent:
Start the development server on port 8080, bound to 0.0.0.0.
Then publish the port from another terminal on the host:
$ sbx ports my-sandbox –publish 8080:8080
Open http://localhost:8080 in your browser. It’s possible to work interactively this way, but there’s more ceremony than opening a project already on your filesystem.
An environment file can make setup repeatable, selecting tools and cloning the repository at creation with something like the community github-clone kit. Recreating the sandbox then gives you a fresh environment. Push or copy out work you want to retain first: removing a sandbox deletes files held only there.
Choose the repositories for the job
An API change might need a corresponding frontend change, or another repository might provide useful reference material. You can mount several directories into one sandbox, with read-only access for reference repositories. Local editing and previews remain available, but each writable checkout needs branch and change coordination. Task-specific checkouts also leave directories to clean up afterward.
A workspace manager such as jganoff/wsp can assemble selected repositories for a task. Mounting that workspace gives the agent the projects it needs together. These are standard clones with their own Git metadata, so the agent retains Git access, unlike a mounted linked worktree.
The same scope fits inside a mountless sandbox: clone the repositories needed there and keep the whole workspace in the sandbox. The number of repositories and where their files live are separate choices.
Combine the choices to suit the work
The checkout’s location, the sandbox’s lifetime, and the repositories it contains are choices you can combine. You can keep a project sandbox around for many tasks, or mount a workspace assembled for one job. What suits you may change when you want to work more closely with the agent, or give it more room to manage the work itself.
The Git workflows documentation covers the mechanics of direct mounts, clone mode, and host worktrees.
Quelle: https://blog.docker.com/feed/
Starting today, Amazon Aurora MySQL-Compatible Edition 3 (compatible with MySQL 8.0) supports MySQL 8.0.46, which includes community MySQL fixes and Aurora-specific improvements. In addition to operational improvements, Aurora MySQL 3.14 introduces support for post-quantum TLS (PQ-TLS) key exchange, providing you with post-quantum cryptography options for encrypting your data in-transit. For detailed information on this release, refer to Aurora MySQL 3 and MySQL 8.0.46 release notes.
You can upgrade your databases during scheduled maintenance windows using automatic minor version upgrades. To simplify operations at scale, enable automatic minor version upgrades and use the AWS Organizations Upgrade Rollout Policy to orchestrate upgrades across your clusters in phases. You can perform minor version upgrades in-place or via snapshot restore. This release is supported in all AWS Regions where Aurora MySQL is available.
Amazon Aurora is designed for high performance and availability at global scale with full MySQL compatibility. It provides scale-to-zero serverless compute, Aurora Global Database for multi-Region resilience, Aurora I/O-Optimized for improved price performance on I/O-intensive workloads, and built-in security and continuous backups. To get started, take a look at Aurora’s getting started page.
Quelle: aws.amazon.com
Starting today, Amazon Aurora MySQL-Compatible Edition 8.4 supports MySQL 8.4.10. We recommend upgrading to the newer minor versions to accept fixes for Common Vulnerabilities and Exposures (CVEs) in prior versions of MySQL and to benefit from bug fixes, performance improvements, and new functionality added by the MySQL community. For more details, refer to the Aurora MySQL 8.4 and MySQL 8.4.10 release notes.
Aurora MySQL 8.4.10 adds support for global transaction identifiers (GTID) tags, which lets you assign a user-defined tag to GTIDs to help you identify and group related transactions in binary log replication. This release also adds support for a maximum of 50,000 simultaneous connections per DB instance, which allows connection-intensive applications to scale without adding a connection pooling layer. Learn more about maximum connections best practices in the Amazon Aurora MySQL User Guide.
You can upgrade your databases during scheduled maintenance windows using automatic minor version upgrades. To simplify operations at scale, enable automatic minor version upgrades and use the AWS Organizations Upgrade Rollout Policy to orchestrate upgrades across your clusters in phases, validating on lower-priority environments before upgrading your most critical ones. You can perform minor version upgrades in-place or via snapshot restore. Learn more about performing version upgrades in the Amazon Aurora User Guide. This release is supported in all AWS Regions where Aurora MySQL is available.
Amazon Aurora is designed for high performance and availability at global scale with full MySQL compatibility. It provides scale-to-zero serverless compute, Aurora Global Database for multi-Region resilience, Aurora I/O-Optimized for improved price performance on I/O-intensive workloads, and built-in security and continuous backups. To get started, take a look at Aurora’s getting started page.
Quelle: aws.amazon.com
For organizations that use Amazon Quick, the desktop application now signs users in with the same sign-in method the organization already uses for Quick on the web. Administrators no longer need to register an OIDC application in their identity provider or set up separate desktop sign-in before users can get started. If a user can sign in to Quick on the web, that user can sign in to the desktop application.
To turn on desktop access, an administrator adds the desktop connector once in the Amazon Quick console. Users then enter their Quick account name, choose Sign In, and finish signing in through their browser. This works for accounts that use IAM Identity Center, IAM federation, or native Amazon Quick users. If your organization wants to manage desktop sign-in separately, you can still set up a dedicated identity provider configuration with providers such as Microsoft Entra ID, Google Workspace, Okta, or Ping Identity.
Amazon Quick on desktop is available in AWS Regions that support the full Amazon Quick feature set.
To get started, see Amazon Quick on desktop in the Amazon Quick User Guide.
Quelle: aws.amazon.com
Starting today, Amazon RDS supports per snapshot billing for Amazon RDS snapshots. Per snapshot billing allows you to get the cost of each individual snapshot.
Previously, RDS snapshot charges were aggregated at the database instance level on the Cost and Usage report as well as the Cost Explorer. This meant that while understanding the snapshot charges, you could only see the aggregate view at the database instance instead of drilling down to each individual snapshot. Now, you can use cost allocation tags on your snapshots to see exactly how much each snapshot costs, giving you a better understanding of your backups spend and budgets. Per snapshot billing is enabled by default on all RDS snapshots for no additional charge.
Per snapshot billing is available for all Amazon RDS engines in all commercial AWS Regions and the AWS GovCloud (US) Regions. To learn more, please visit our documentation.
Quelle: aws.amazon.com
