Alongside the severity they already carried, findings now show the attack possibility and the urgency derived from the two, so a report tells you not only how serious a finding is but which one to address first.

Overview​

Severity measures how much damage results once an attack succeeds, and says nothing about whether that attack is realistically achievable. As a result, a critical finding that depends on preconditions no ordinary attacker can meet used to sit alongside a critical finding anyone can reproduce.

The newly added attack possibility rates that missing half — whether the attack can realistically be pulled off — on a scale from High down to Impossible. Urgency then follows from the combination of severity and attack possibility. It is not judged on its own, so read it when deciding which findings to fix first.

The report's overall A-E rating now follows the highest urgency among the findings it contains, and the findings list is ordered by urgency, so you can work through the report from the top.

Note that the new criteria apply only to reports from assessments started from now on. Findings reported by past assessments are unchanged.

Some reports may also show "—" as the attack possibility and urgency of a finding. An assessment that started before the attack possibility became available can still carry findings that were never rated on it, and without that scale no urgency follows either. Those findings are listed after the rated ones and are not reflected in the report's overall rating, so judge them by their severity and by what the finding says.

▼ User Guide: Severity, Attack Possibility, Urgency

No credit card required — just create a Takumi organization and Takumi Runner accepts trace logs for up to 3,000 minutes of CI/CD job run time per month. Every feature that makes use of the trace logs is available too, including Trace Search and Threat Detection, so you can check and detect the impact of supply-chain incidents free of charge.

Overview​

Until now, using the cicd-sensor integration required a Takumi subscription and Runner enabled. Starting today, with the free tier, all it takes is creating a Takumi organization.

What You Can Use​

All the trace log investigation features are available.

Trace log visualization

You can review the visualized trace data in the Takumi Runner console.

Trace log search

From the Takumi Runner console, you can search the contents of the collected trace logs. You can check whether the CI/CD jobs that ran during a supply-chain incident were affected.

Threat detection

Threat detection proactively investigates the impact of a supply-chain incident based on the trace logs and notifies you if you are affected. Since it removes the need to investigate yourself, it addresses gaps in expertise and the risk of missing an incident.

When You Exceed the Free Tier​

The free tier accepts trace logs for up to 3,000 minutes of total job run time per organization per month. Once the 3,000-minute limit is reached, trace logs are no longer accepted after that point, but your CI/CD jobs still run as usual.

To manage trace logs in Takumi Runner beyond 3,000 minutes, you need a Takumi subscription and Runner enabled.

For the pricing details of the cicd-sensor integration and Takumi Hosted Runner, see Pricing & Billing.

Getting Started​

The steps to start using the free tier are as follows.

Creating an Organization​

Go to https://cloud.shisho.dev/hello/takumi.

1. Turn on Create a new organization and enter the ID of the organization to register
2. Press Create a new organization

Once the organization is created, next set up the cicd-sensor integration.

Setting Up the cicd-sensor Integration​

Here we walk through the setup for CI/CD jobs on GitHub-hosted runners. If you use another environment, see the user guide.

Credentials

First, create a bot that handles the credentials. In the Takumi console, open Settings > Bots > Add bot and select Takumi Runner Trace Sender to open the bot creation screen.

On the bot creation screen, set up a trust condition. Enter the name, organization, and repository.

Press save to finish creating the bot. Next, create a GitHub workflow.

Creating a GitHub job

Here we create a job that runs echo Hello.

jobs:
  build:
    runs-on: ubuntu-latest
    environment: cicd-sensor
    permissions:
      contents: read
      id-token: write
    steps:
      - id: auth
        uses: flatt-security/shisho-cloud-action@v1
        with:
          bot-id: <Bot ID>
          export-token: true
          expires-in-minutes: 360
      - uses: cicd-sensor/cicd-sensor-action@6511eb44c91d71b2b93d71193b1bf2cb18352f66 # v0.0.38
        with:
          manager-url: https://manager.cicdsensor.cloud.shisho.dev
          manager-token: ${{ steps.auth.outputs.token }}
      - run: echo Hello

The uses: flatt-security/shisho-cloud-action@v1 step obtains the credentials. The uses: cicd-sensor/cicd-sensor-action step runs cicd-sensor.

The connection to Takumi Runner is configured with manager-url: https://manager.cicdsensor.cloud.shisho.dev.

Checking the Trace Logs​

Run the job above and the run becomes visible in the Takumi Runner console. Open Runner on the left side of the screen, and completed jobs appear under Recent Jobs.

Click a job to see its trace logs. From here, you can use the various features for working with trace logs introduced above.

For more details on the cicd-sensor integration, see the user guide.

What the Alpha Test Does​

The initial alpha focuses on asset discovery. Takumi uses publicly available information and performs only minimal crawling of the assets it finds. It does not attempt logins, perform malicious actions, or run invasive tests against your applications.

For each ASM run, approximately two browser accesses per asset is the general guideline for the traffic sent. The execution frequency during the alpha test will vary depending on development and testing needs. To minimize the impact on target assets, ASM runs associated with any single organization will be limited to a maximum of five per hour.

What Participants Receive​

After the alpha test concludes, we plan to provide each participating organization, where possible, with a data-based list of the assets discovered for it. These results can help you identify shadow assets that were not previously known within your organization, update your inventory of internet-facing assets, and inform the scope and priorities of future vulnerability assessments and penetration tests.

Results will not initially be available in the Takumi user interface, and the alpha test does not guarantee comprehensive asset discovery.

Your participation and feedback will help improve how Takumi associates assets with their owners and prioritizes the assets that warrant closer review.

Future Plans​

We plan to extend ASM so that it can select discovered attack-surface assets for review with Takumi's penetration testing capability and, where appropriate, automatically assess those targets. The alpha test itself does not perform these penetration tests.

ASM is planned as a paid Takumi capability in the future.

How to Participate​

To join the free alpha test, contact your GMO Flatt Security sales representative or email shisho-support@flatt.tech.

You can use the following email template when applying:

Subject: Application for the Takumi ASM Alpha Test

I would like to apply to participate in the alpha test of Takumi's ASM capability.
Please use the following domains as starting points for asset discovery:

- aaa.example (known subdomain: xxx.aaa.example)
- bbb.example

Please include a list of domains that your organization knows it owns. We will use these domains as starting points for asset discovery. You may share only what you are comfortable providing, but please include at least one domain. If you would be open to providing further assistance with product improvement, we would also appreciate a list of subdomains associated with those domains. This information will help us evaluate and improve discovery accuracy.

Benefits​

Until now, you had to review and investigate the trace logs collected by Takumi Runner yourself. Investigating them effectively requires a certain amount of expertise, and the response needs to be fast.

With this feature, when a supply-chain incident occurs, an impact investigation that leverages our know-how and systems is carried out promptly, and you are notified if you are affected.

Getting Started​

To receive notifications, you need to enable threat notifications in the settings.

In the Shisho Cloud console, open Runner > Settings and configure the destination under Threat Notifications.

Turn on the Email notifications toggle and choose the destination address from Target address. Press "Save" and the setup is complete: notifications will be sent when a threat is detected in a future incident.

You can also send a test from this screen to confirm in advance that notifications arrive correctly.

For details, see the Threat Detection user guide.

Pricing​

Threat detection is included in the Takumi Runner base plan. It is not metered.

For details on Takumi Runner plans, see Pricing & Billing.

Getting Started with Takumi Runner​

To use Takumi Runner, you need a Takumi subscription and Runner enabled.

1. Go to https://cloud.shisho.dev/hello/takumi and sign in
2. Register your organization and subscribe to Takumi
3. Open Runner > Settings from the sidebar on the left
4. Click the "Enable" button to enable Runner

Once Runner is enabled, follow the Takumi Runner user guide to complete the setup.

cicd-sensor trace logs also work with the threat detection feature released today.

Background​

Takumi Hosted Runner collects eBPF traces — process executions, network connections, DNS queries, and file accesses — by running jobs on Takumi Runner's dedicated runners. On the other hand, moving jobs to Takumi Hosted Runner is sometimes difficult, whether due to execution environment constraints or the effort of migrating.

For those cases, we now provide a way to use cicd-sensor, which requires no migration of the execution environment. Add cicd-sensor to a CI/CD pipeline and specify Takumi Runner's Manager endpoint and credentials, and the trace logs will be sent to Takumi Runner.

As the architecture figure above shows, Takumi Hosted Runner collects trace logs by running CI/CD jobs on dedicated runners that we operate. The cicd-sensor integration instead adds cicd-sensor to the environment you already use — GitHub-hosted runners, self-hosted runners you operate yourself, and so on — and sends the logs traced there to Takumi Runner.

Benefits​

Trace logs collected through cicd-sensor are managed the same way as Takumi Hosted Runner trace logs, so trace log visualization, search, and threat detection are all available for them.

Trace log visualization

You can review the visualized trace data in the Takumi Runner console.

Trace log search

Takumi Runner lets you search the contents of the collected trace logs. You can check whether the CI/CD jobs that ran during a supply-chain incident were affected.

Threat detection

Threat detection proactively investigates the impact of a supply-chain incident based on the trace logs and notifies you if you are affected. Since it removes the need to investigate yourself, it addresses gaps in expertise and the risk of missing an incident.

Supported CI/CD pipelines​

The cicd-sensor integration does not depend on the execution environment, so as a rule it supports the CI/CD pipelines that cicd-sensor supports. At the time of writing, GitHub Actions and GitLab CI/CD are supported. For GitLab CI/CD, self-hosted GitLab Runners (Docker executor) are covered.

Getting Started​

The cicd-sensor integration takes three steps:

1. Add cicd-sensor to the CI/CD job
2. Set Takumi Runner's Manager as cicd-sensor's manager-url
3. Set the credentials as cicd-sensor's manager-token

GitHub-hosted runners​

Add the cicd-sensor step at the beginning of the job and specify the Manager endpoint in the manager-url parameter.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: cicd-sensor/cicd-sensor-action@6511eb44c91d71b2b93d71193b1bf2cb18352f66 # v0.0.38
        with:
          manager-url: https://manager.cicdsensor.cloud.shisho.dev
          manager-token: ${{ secrets.SHISHO_CICD_SENSOR_TOKEN }}

Authentication (manager-token) is performed through a Shisho Cloud bot. For how to set up authentication, including creating the bot, see the user guide.

Once the job execution completes, the job and its traces are reflected in the Takumi Runner console.

GitHub self-hosted runners and GitLab CI/CD​

In these environments, cicd-sensor runs on the runner's host, so installing cicd-sensor and configuring the Manager endpoint happen on the host rather than in the pipeline. For how to set this up, see the cicd-sensor documentation.

Takumi Runner's Manager endpoint is https://manager.cicdsensor.cloud.shisho.dev.

For the credentials, issue an API key in the Takumi console and specify it as the manager-token. For details on creating a bot and API keys, see the user guide.

Pricing​

The cicd-sensor integration requires the Takumi Runner base plan.

Within the base plan, we accept trace logs for up to a total of 3,000 minutes of job run time per month. From September 1, 2026, accepting logs for job runs beyond 3,000 minutes incurs a per-minute fee.

For details on the cicd-sensor integration pricing, see Pricing.

Getting Started with Takumi Runner​

To use Takumi Runner, including the cicd-sensor integration, you need a Takumi subscription and Runner enabled.

1. Go to https://cloud.shisho.dev/hello/takumi and sign in
2. Register your organization and subscribe to Takumi
3. Open Runner > Settings from the sidebar on the left
4. Click the "Enable" button to enable Runner

Once Runner is enabled, follow the cicd-sensor integration user guide to complete the setup.

Specify both your source code and the URL of the application running that code. Takumi analyzes the code to enumerate candidate vulnerabilities and attacks the running application, then reports only the ones it manages to reproduce as findings.

Overview​

Whitebox assessment reads the source code directly, so it can find vulnerabilities that an external investigation — that is, a blackbox approach — could never reach. What the code cannot tell you is whether a candidate it surfaces actually reproduces in the environment you run. Blackbox assessment reports only vulnerabilities that do reproduce in that environment, but it struggles with vulnerabilities that are hard to find without reading the code, and with those hidden in functionality that is not publicly exposed.

Graybox assessment takes the strengths of both. Static analysis enumerates candidate vulnerabilities comprehensively, and every candidate is then verified for reproducibility against the running application, so the assessment delivers coverage and accuracy at the same time.

Reports Backed by Reproduction​

Every finding recorded in a graybox report was reproduced against your running application. Candidates that static analysis raised but dynamic verification could not reproduce are recorded in a separate section of the report instead of as findings, so reading the report is enough to tell which vulnerabilities actually reproduce.

Each finding also documents the procedure used to reproduce it. A developer can follow the same steps to confirm that the vulnerability occurs, and can run them again after a fix to verify that the fix holds.

Getting Started​

This feature is available to all "Takumi byGMO" users and can be freely used within your monthly credit allowance. No additional fees or plan changes required.

Click the "Create Assessment" button in the "Assessment" tab of the global sidebar, then select "Graybox Assessment".

▼ User Guide: Graybox Assessment

Overview​

Takumi did not support MFA by email, so it had to be turned off for every assessment to run properly.

With this release, blackbox assessments and penetration tests let you pick an email address that Takumi can receive mail at during the assessment.

This is not limited to one-time codes for MFA — it covers any feature that relies on email, such as magic links and sign-up confirmation messages.

Getting Started​

This feature is available to all organizations from the blackbox assessment and penetration test dispatch screens.

When you add a credential, select "Takumi-managed email" as the account email, then either issue a new address or pick one your organization already holds. Up to 5 addresses can be registered.

For how to configure the address and register it on the target application, see Signing In With an Emailed One-Time Code.

We have published a workflow that addresses this issue, so please update yours.

Background​

In March 2026, AWS introduced express configuration, a way of creating Aurora clusters.

Unlike conventional Aurora clusters, a cluster created with express configuration is not associated with a VPC.

The managed review item "Ensure that RDS instances are deployed in a VPC" (RDS.18) judges VPC membership from the DB subnet group the DB instance refers to. Aurora clusters created with express configuration therefore fall outside this premise and could not be judged correctly.

Anticipating that Aurora clusters in this configuration will come into use, we would appreciate your cooperation in updating this review workflow to prevent incorrect review results.

What to Update​

The target of this update is a single job in the following workflow.

What You Need to Do​

The latest GraphQL query and Rego policy are available in the workflows/csp/aws-fsbp/rds/instance-vpc directory of the shisho-cloud-managed-workflows repository. Please replace yours with them.

For reference, "Ensure that RDS instances are deployed in a VPC" (RDS.18) has already been removed from the review items of its source standard, AWS FSBP (AWS Foundational Security Best Practices standard).

Depending on your operational situation, removing the job itself is therefore also an option.

Depending on how you manage your workflows, update through one of the following methods. If the workflow does not appear in your workflow list, no update is needed.

Updating with shishoctl​

If you have workflow definitions obtained with shishoctl workflow export, replace the files corresponding to the instance-vpc job (the Rego policy, the GraphQL query, and the test) with the latest contents, and apply them to your organization with shishoctl workflow apply.

Editing in the Console​

Open "Prebundle: Review AWS RDS posture (FSBP)" from Workflows, find the job with id: instance-vpc under jobs in the manifest, and replace the contents of rego: in the decide block (the Rego policy) and schema: under input (the GraphQL query) with the published versions, then save.

No changes to other jobs or parameters are needed.

Managing Workflows in a GitHub or GitLab Repository​

Replace the three files corresponding to the instance-vpc job (the Rego policy, the GraphQL query, and the test) with the latest contents and push to your main branch.

Your deployment workflow, such as a configured GitHub Actions workflow, applies the changes to Shisho Cloud automatically.

Contact​

If you have any questions or concerns about the update, please contact our support desk.

We will assist you according to your situation.

We have also improved how accurately Takumi finds the paths that lead to a given objective, along with the safeguards that keep a test running safely.

Expanding Availability​

We have been introducing AI penetration testing to pre-registered customers in stages. Having accumulated operational experience, and having strengthened the safeguards that keep tests running safely, we are now widening that rollout further.

We continue to onboard pre-registered customers in order, so if you'd like to use the feature, start by registering from the application page.

Improvements​

Since our last announcement, we have made three improvements to exploration accuracy and to the safeguards that keep tests running safely.

• Engine performance: Takumi is more accurate across the chain of judgments it makes — forming hypotheses from reconnaissance, chaining vulnerabilities, and turning each foothold into the next attack
• Destructive operation policies: You can now define in advance how far Takumi may go with operations that could affect the target system, such as deleting or modifying data
• Stronger scope control and monitoring: We have strengthened both the controls that keep exploration from reaching outside the configured scope and the detective controls that surface access to out-of-scope targets and other risky operations

Customer Feedback​

宮﨑 多朗様 (ウェルスナビ株式会社 システム基盤グループ/セキュリティエンジニア) shared the following feedback with us.

これまでペネトレーションテストは専門会社に依頼するとコストが高くなる傾向があり、数百万円〜の費用に加え、シナリオの相談からレポート受領まで2ヶ月以上を要することもめずらしくありません。予算の確保や社内調整、さらに診断員のスケジュール調整にも時間がかかるため、私たちとしてもフットワーク軽く回すことが難しいという課題がありました。

Takumi の AIペネトレーションテスト機能では、従来であれば100万円を超える規模を見込むようなペネトレーションテストが、今回は数千円・数時間という圧倒的なコストとスピードで完了しました。専門会社の診断員のスケジュールに左右されず、必要なタイミングで自分たちの判断ですぐに実施できる点も大きな魅力です。事業会社が抱えるセキュリティエンジニアの数は必ずしも多くない組織もあるなかで、こうした調整ごとにかかる工数を短縮してくれるため、専門的な知識を持つメンバーはシナリオの設計・調整といった本質的な部分に注力できるようになりました。手軽に回せるだけでも十分な価値ですが、机上の評価では正直「刺さらないだろう」と考えていた箇所にミスコンフィギュレーションが見つかり、実際のリスクとして検知してくれた点には驚かされました。手軽さだけでなく成果の面でもしっかり応えてくれるため、私たちとしても今後、Web 経由のペネトレーションテストを積極的に活用していきたいと考えています。

Getting Started​

AI penetration testing is currently expanding its availability in stages.

▼ User Guide: Penetration Testing

Self-hosted CI/CD systems such as Jenkins, Buildkite, and CircleCI, another cloud's workload identity federation, GitHub Enterprise Server, and self-managed GitLab can all sign in as a bot without a static API key.

Overview​

A trust condition is a rule, configured on a bot, that decides which OIDC ID tokens Shisho Cloud accepts as proof that the caller may sign in as that bot. Until now it understood two issuers, GitHub Actions and GitLab CI, so every other environment had to fall back on a bot API key - a static secret you have to store, rotate, and keep out of your logs.

The new Custom (OIDC) provider lets you point a trust condition at your own issuer instead. Your identity provider mints a short-lived ID token for each job, Shisho Cloud verifies it against the condition, and exchanges it for equally short-lived credentials scoped to that bot. Nothing persistent has to live on the CI side.

Getting Started​

Open a bot's Trust Conditions tab in the Shisho Cloud console, add a trust condition, and select Custom (OIDC) as its provider. The condition takes three required inputs, plus an optional one.

• Issuer - the https:// URL of the ID token's issuer. It must be reachable on port 443 and serve an OIDC Discovery document at /.well-known/openid-configuration.
• Subject - the expected value of the ID token's sub claim, either an exact string or an expression in which * matches any sequence of characters, such as repo:acme/app:*. A subject of just * is rejected.
• Audience - the value the ID token's aud claim must contain. We recommend configuring your provider to issue https://sts.cloud.shisho.dev, so a token minted for Shisho Cloud can't be replayed against another relying party.
• Claims (optional) - up to 10 additional conditions on other top-level string claims of the token, each matched the same way as Subject.

Once the condition is saved, the CI-side flow is the same as for GitHub Actions or GitLab CI. Obtain an ID token from your provider, then pass it to shishoctl auth signin:bot.

For the full field reference, an example configuration, and security guidance, see Custom OIDC in the bot authentication guide.

Instead of crawling with a web browser, Takumi extracts the endpoints to assess from the attached schema files, such as an OpenAPI specification or a GraphQL schema.

Overview​

Blackbox assessments have relied on crawling a web browser to discover the endpoints to assess. This works well for applications operated through a browser, but not for APIs that serve no screen — there is nothing to crawl, so they could not be assessed. Many real-world targets, however, are API-only, such as backends for mobile apps and service-to-service APIs.

With this release, Takumi can assess those UI-less APIs directly. When you select API as the target type, Takumi does not crawl; it extracts the endpoints from the attached schema files instead.

Getting Started​

This feature is available to all organizations from the blackbox assessment dispatch screen.

For how to configure the schema files and authentication steps, see Assessing an API.

Set a target and a concrete objective — such as accessing user data — and Takumi autonomously chains reconnaissance, vulnerability discovery, and exploitation.

The feature is not yet available to all customers, so if you'd like to use it, register from the application page.

Background​

Whitebox and blackbox assessments comprehensively detect vulnerabilities across an entire application using a feature-and-perspective matrix. In real-world operations, however, you often want to answer more than "what vulnerabilities exist" — you want to know whether an attacker could actually reach a specific objective in this environment. Individually minor weaknesses frequently chain together into a serious outcome, such as data exfiltration or a full system compromise.

AI penetration testing answers that question. Rather than enumerating every vulnerability, it focuses on whether a single defined objective is reachable, and Takumi autonomously explores the attack paths that lead to it. Much like a human penetration tester, it forms hypotheses from what it learns during reconnaissance, discovers and chains vulnerabilities, and turns each foothold into the next attack.

How It Works​

You start a run by configuring a target and an objective. Pick an objective from presets such as "accessing user data" or "gaining system access," and Takumi handles everything from reconnaissance to exploitation. Unlike a standard assessment, it doesn't just report vulnerabilities individually — it verifies how those vulnerabilities can be leveraged to actually reach the objective.

While a test runs and after it completes, you can follow a timeline of what the attack has reached and an intrusion map that visualizes the discovered attack paths. When the test finishes, Takumi produces a report of the operations it performed and whether the objective was achieved. Even if the objective was not reached, you can review the report, add further instructions, and resume the test from where it left off.

For more detailed configuration and usage, see the user guide.

Getting Started​

AI penetration testing is currently expanding its availability in stages.

▼ User Guide: Penetration Testing

The images are published through the OCI registry images.flatt.tech.

Overview​

Development teams are being asked to apply security updates more frequently, while software supply chain attacks increasingly target the update process itself. Takumi Images is designed to reduce that operational tension: you can move to maintained base images without rebuilding your own patch pipeline for common runtime images.

When a corresponding image is available in the catalog, you can switch the base image reference and pull the latest Takumi image when updates are published, instead of investigating base-image packages, selecting patched dependency versions, and rebuilding those images yourself.

Getting Started​

When the catalog includes a Takumi image that corresponds to your current base image, migration usually only requires changing the FROM line in your Dockerfile:

- FROM node:latest
+ FROM images.flatt.tech/takumi/node:latest

After migration, pull the image again to receive the latest rebuilt image:

docker pull images.flatt.tech/takumi/node:latest

For details, see the Takumi Images documentation.

Included Value​

Takumi Images makes base-image maintenance easier in three ways.

First, each image contains less by default. Takumi Images focuses on the main program and the minimum runtime libraries required to run it. This helps reduce scanner noise from dependencies that are inherited from the base image rather than from your application code.

Second, the provider handles the base-image side of the investigation. For software included in Takumi Images, the provider triages vulnerability impact and also checks upstream code for malware before incorporating updates. This reduces the amount of base-image findings and update-source risk that users have to track themselves.

Third, each image is published with verifiable supply chain metadata:

• Signed image artifacts
• SBOM attestations
• SLSA Provenance attestations
• VEX attestations for vulnerability findings assessed by the provider

These attestations let you inspect what is in the image, where it came from, and the current assessment for findings reported against the base image.

Roadmap​

We plan to expand the image catalog further, focusing on databases, language runtimes, and middleware, and to provide image variants that address compliance requirements.

We also plan to detect vulnerability information before CVE IDs are assigned, incorporate those fixes early through nightly builds, and support international compliance requirements.

This page also walks through how to use the search feature with real-world examples, such as the axios supply chain attack in March 2026. See Examples below.

Getting Started​

In the Shisho Cloud console, open Runner > Trace Search.

First, choose a date range and select the event types you want to search. Enter your search criteria and click Search to start the search.

Once the search completes, you can review the search results. From this screen you can:

• Review statistics for the matched jobs and events
• Inspect the matched jobs and events in detail
• Download the search result data

Search results are retained for 72 hours.

For details, see the trace search documentation.

Examples​

Axios supply chain attack - hostname search​

In March 2026, the npm package for the HTTP client library axios was compromised in a supply chain attack. For details on this incident, see our blog post.

Suppose an equivalent attack occurred three days ago. Based on our blog post and similar reports, the malware connects to dangerous.example (this page uses a fictional hostname that differs from the real one cited in the blog post).

Use the following search criteria to check whether any jobs executed by Takumi Runner were affected:

• Date range - <3 days ago> ~ <day of search>
• Event type - dns_query
• Hostname - *dangerous.example

Add * at the beginning of the hostname so subdomains also match.

Run the search. If any jobs match, you can conclude they were affected by the attack.

GitHub Actions compromise - file access search​

Attacks that compromise GitHub Actions and steal credentials have already occurred several times this year. For details, see our blog post.

Now suppose a similar GitHub Actions compromise occurred. Based on the blog post above, a typical pattern is reading credentials from process memory at /proc/<pid>/mem. If your jobs were affected, Takumi Runner retains trace data showing file access to /proc/<pid>/mem.

You can check for impact with the following search criteria:

• Date range - <attack date> ~ <day of search>
• Event type - file_open
• File path - /proc/*/mem

Since <pid> is not fixed, use * in the search.

Run the search. If any jobs match, you can conclude they were affected by the attack.

Overview​

Previously, viewing installation logs meant searching one package at a time. The new Log Browser keeps that search and adds organization-wide browsing and breakdowns in the same screen, so you can move from "did anyone install this package?" to "what is this repository pulling?" without switching pages.

It replaces the previous per-package log page — the package search you used before is now one mode within the browser.

Getting Started​

Navigate to Guard > Logs in the Shisho Cloud console. Choose your ecosystem (npm, PyPI, RubyGems, and others), then either search a package or browse recent activity.

Key Capabilities​

One screen for search and browse​

Search a specific package to see every installation — who installed it, from which repository and workflow, and when — or browse all installation events across your organization from the same place.

Group by repository, workflow, or user​

Switch between a flat events feed and breakdowns grouped by package, repository, workflow, or user, each with download and blocked counts. Selecting any entity filters the view down to it, which is the quickest way to narrow an investigation.

One time range, applied everywhere​

A single range — 24 hours, 7 days, 14 days, or a custom range up to 14 days — scopes the summary, the events feed, and the breakdowns together, so every number on screen covers the same window. You can also filter to blocked installations only.

Always know what you are looking at, and share it​

A summary bar above the results states the active ecosystem, time range, and filters, and lets you clear each one. The current view is captured in the page URL, so you can send a teammate a link that reproduces the exact evidence on screen.

Notes​

Installation logs remain searchable for 14 days, and data is updated approximately every 15 minutes. Log queries are subject to a per-organization fair-use limit — 60 requests per minute and 5,000 per day — to keep the browser responsive for everyone. For full details, see the Package Installation Logs guide.

Overview​

Admin deployment lets administrators roll Takumi Guard out across their fleet without any per-developer steps: the setup script is distributed through your management tool (Jamf, Intune, Ansible, and so on) and silently configures every supported package manager on each device. That list covered npm, PyPI, RubyGems, and Go modules; Packagist now joins it as the fifth ecosystem, so PHP projects get the same protection as the rest, with nothing for individual developers to do.

On each device the setup script registers Takumi Guard as a Composer repository and disables the public Packagist (packagist.org), so composer install and composer update resolve through Takumi Guard and known-malicious packages are blocked before they are fetched. It configures Composer via the official composer config command when composer is on PATH, and writes the config files directly otherwise — so protection still lands in MDM contexts where the CLI is not reachable.

Getting Started​

Setup script v0.10.0 is available from:

• macOS / Linux: https://shisho.dev/releases/takumi-guard-setup-0.10.0.sh
• Windows: https://shisho.dev/releases/takumi-guard-setup-0.10.0.ps1

Steps (if you already have a Bot and API key, skip to step 3):

1. Create a Bot in the Shisho Cloud console (Settings > Bots) and assign the "Takumi Guard Token Issuer" role
2. Generate an API key for the Bot
3. Download the setup script v0.10.0 from the URL above
4. Wrap the script with your management tool (Jamf, Intune, Ansible, etc.) and deploy

All of npm, PyPI, RubyGems, Go modules, and Packagist are configured by default; pass packagist as the scope argument to target it alone. For detailed instructions and the latest wrapper examples, see the Admin Deployment guide.

Developers configuring Composer on their own machine or in CI can follow the Packagist quickstart instead.

Getting Started with Your Organization​

To use Guard's organization features (admin deployment, installation log search, etc.), you need a Takumi subscription with Guard enabled.

1. Go to https://cloud.shisho.dev/hello/takumi and sign in
2. Register your organization and subscribe to Takumi
3. Navigate to Guard > Settings from the sidebar
4. Click "Enable" to activate Guard

Once Guard is enabled, follow the Admin Deployment guide to begin setup.

Overview​

After running setup.sh install, there was no automated way to confirm Guard was working end-to-end. The user guide provided manual verification steps (e.g. npm install @panda-guard/test-malicious), but these were easy to skip and not scriptable.

The healthcheck subcommand closes this gap. It runs a 3-phase verification for each supported ecosystem:

1. Config check — verifies the package manager is pointing to the Guard proxy
2. Connectivity check — confirms the Guard proxy is reachable
3. Block test — attempts to install a known-blocked test package and verifies it is rejected

The subcommand is completely read-only and requires no API credentials (TG_BOT_API_KEY / TG_BOT_ID are not needed).

Getting Started​

Run the healthcheck after completing setup.sh install:

./setup.sh healthcheck

To check a specific ecosystem:

./setup.sh healthcheck golang

Exit codes​

The healthcheck uses exit codes to signal the result, making it easy to integrate into management tool workflows and automation:

Example output​

$ ./setup.sh healthcheck golang

[OK] go: GOPROXY → https://golang.flatt.tech
[OK] go: Guard proxy reachable
go: creating new go.mod: module healthcheck-tmp
[OK] go: sentinel module hola-takumi-go@v0.1.0 correctly blocked

[OK] All healthchecks passed

Supported Ecosystems​

The healthcheck currently supports npm, RubyGems, and Go. PyPI support will be added in a future update once a test package is published.

For full documentation on the healthcheck subcommand, see the Admin Deployment — Healthcheck section of the user guide.

Background​

npm v11.15.0 introduced enforcement of the --allow-remote supply chain control. With this check, a dependency whose tarball download URL points to a host different from the configured registry is classified as a "remote" dependency, and downloads of such transitive dependencies are rejected.

Previously, Takumi Guard served upstream registry.npmjs.org tarball URLs to npm clients verbatim. Under the new check, npm sees a mismatch between the configured registry (npm.flatt.tech) and the tarball host, so installs through Takumi Guard could fail with EALLOWREMOTE errors on npm v11.15.0 and later.

Takumi Guard now rewrites tarball URLs to its own host for npm v11.15.0+ clients, which restores the correct "registry" classification. Upcoming npm releases are set to tighten these checks further — for example, by also requiring tarball URLs to live under the configured registry's path — so this change is a necessary step to keep Takumi Guard compatible with current and future npm versions.

What Changes​

npm v11.15.0 and later​

Lockfile (package-lock.json) entries that are added or updated will record Takumi Guard's registry URL (https://npm.flatt.tech/...) in their resolved fields instead of the upstream registry.npmjs.org URL. This is expected behavior and is necessary for installs to work under npm's supply chain checks.

Package integrity is unaffected — integrity hashes are unchanged, and npm audit signatures continues to verify registry signatures and attestations as before.

npm versions before v11.15.0​

No change. Older npm clients continue to receive upstream tarball URLs, and their lockfiles are unaffected.

pnpm, Yarn, and Bun​

No change in this release. pnpm does not record full tarball URLs in pnpm-lock.yaml, so its lockfile never contains registry hosts. Yarn v1 already records Takumi Guard's URL in yarn.lock as described in a previous release note; Yarn v2–v4 (Berry) and Bun are unaffected.

Recommendation​

If you prefer to keep registry URLs out of your lockfile entirely, consider migrating to pnpm. pnpm does not embed tarball URLs in its lockfile, works seamlessly with Takumi Guard, and offers strong supply chain security features out of the box.

PHP projects using Composer can now route composer install and composer update through Takumi Guard to block known-malicious packages before they reach your CI or development environment.

Overview​

Takumi Guard is a security proxy that sits between your package manager and the upstream registry. It checks every install request against GMO Flatt Security's threat database and blocks known-malicious packages.

With this release, the same protection that npm, Python, Ruby, and Go users have is now available for the PHP ecosystem:

• Package Blocking: Malicious packages are blocked before any code is fetched
• Download Tracking: Records install history for authenticated users
• Breach Notifications: Get notified if a package you installed is later flagged as malicious

The proxy speaks the standard Composer repository protocol, the same mechanism used by Private Packagist and Toran Proxy — so no tooling changes are needed, just a one-time repository configuration.

Getting Started​

The following works anonymously — no account or registration required. Add Takumi Guard as a Composer repository and disable the default Packagist.org so every package resolves through the proxy:

composer config --global repositories.takumi-guard composer https://packagist.flatt.tech
composer config --global repositories.packagist.org false

That's the whole setup. Blocking applies to composer install and composer update — including installs from an existing composer.lock (Composer 2.10+), so projects with a committed lock file are protected without any migration step.

GitHub Actions​

Use the flatt-security/setup-takumi-guard-packagist action. Blocking-only requires no account or token — it configures the repository, and your existing composer install is protected (committed lock files included):

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"
          tools: composer:v2
      - uses: flatt-security/setup-takumi-guard-packagist@v1
      - run: composer install --no-interaction

For organization-level download tracking and breach notifications, add a bot-id and grant id-token: write — the action does the OIDC → short-lived-token exchange automatically, no long-lived secret in CI. See the Packagist quickstart for the full pattern.

Verify Your Setup​

Confirm blocking is active by trying to require our published test package, flatt-security/hola-takumi-php — a harmless package that is permanently on the blocklist:

composer require --dry-run flatt-security/hola-takumi-php

This must fail with a flagged-package error. If it resolves successfully, requests are not going through Takumi Guard — re-check composer config --global --list | grep -E 'repositories|packagist'. A package on the blocklist is rejected during composer install, composer update, and composer require. For details, see "Verify Your Setup" in the Packagist quickstart.

Email Registration Unlocks More (Free)​

Register your email to receive notifications if a package you installed is later found to be malicious. Free of charge.

Step 1: Register your email

curl -X POST https://packagist.flatt.tech/api/v1/tokens \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

Step 2: Get your API key from the welcome email. The key is included directly in the email body — no link to click.

Step 3: Store the token so Composer authenticates with it on every fetch

composer config --global --auth http-basic.packagist.flatt.tech token tg_anon_xxxxxx

Composer uses HTTP Basic auth keyed by host name — the username is ignored, and the token goes in the password field. Your installs are now tracked, and you will be notified if a downloaded package is later flagged.

Private Packages​

Public packages go through Takumi Guard; private packages (e.g. a private GitHub repository) should bypass the proxy. Declare them as their own vcs or path repositories alongside the Guard repository, and Composer fetches each package from the repository that provides it. See the Packagist quickstart for details.

Organization-Wide Management, Too​

Running Takumi Guard across your team? Installation log search, centralized org user token management, and breach-notification webhooks are all available for organization-wide operations. Get started with a Takumi subscription (Guard enabled):

1. Go to https://cloud.shisho.dev/hello/takumi and sign in
2. Register your organization and subscribe to Takumi
3. Navigate to Guard > Settings from the sidebar
4. Click "Enable" to activate Guard

Once Guard is enabled, configure your CI or developer machines using the Packagist quickstart.

If you only need a long-lived org token from GitHub Actions, no payment is required. A payment screen appears during organization registration, but you can skip it — simply register your GitHub organization from the Guard page to receive an org token.

Overview of Claude Fable 5 and Our Existing Plans​

Claude Fable 5 is Anthropic's latest AI model, released on June 10, 2026. It is rooted in the same underlying model weights as "Claude Mythos 5", the model widely noted for its strong cybersecurity capabilities. On top of that, it has stronger safeguards against misuse than Mythos 5.

From "System Card: Claude Fable 5 & Claude Mythos 5":

Fable 5 is being released for general access—it has the same underlying model weights as Mythos 5, but has additional safeguards to prevent misuse for cybersecurity and biology.

The Claude Fable 5 and Claude Mythos 5 models have drawn particular expectation and interest for use in cybersecurity.

As a notable result related to these models, "Claude Mythos Preview", the predecessor of Claude Mythos 5, has already contributed to the discovery of 23,000 vulnerabilities (see "Project Glasswing: An initial update"), to the point where government agencies including Japan's Financial Services Agency and Ministry of Health, Labour and Welfare have issued advisories to critical institutions (see the FSA advisory).

In light of this, Takumi byGMO had reported the following plan for the period after the general release of Mythos-class models, with the aim of supporting security engineers who protect Japanese businesses in their use of these models (original).

Deployment plan following the general release of "Mythos-class models"

• AI penetration testing (a new feature in which an AI agent attempts to break into a system until it reaches a goal): deployed and available within at most 5 business days after the model's general release
• AI security assessment and automated fixing (an AI agent automatically discovers and fixes vulnerabilities): we maintain delivery on current-tier models, while adding a mode that lets you specify the use of Mythos-class models (and comparable high-end models), particularly for inspecting and fixing business logic
• "Takumi Guard" and "Takumi Runner" (features that protect the software supply chain): deployed first into our underlying Threat Intelligence platform and used for malware discovery and analysis, resulting in faster and more accurate detection of malicious OSS packages than before

Note: For tasks where our own benchmarks show that a "Mythos-class model" is not necessarily required, we use existing models. This achieves maximum inspection performance at minimum cost.

Our Policy on Claude Fable 5​

After evaluation by our specialist team, we have decided to hold off on deploying Claude Fable 5 for the AI penetration testing feature (the new feature to be released) as we judged it unnecessary for this release, and to instead begin operating it on Opus 4.8 and models of an equivalent tier, which already record sufficient performance. Our approach to other features is the same: in principle, we continue to operate on models other than Fable 5 that deliver sufficient performance.

Background to This Policy​

The background to this policy is as follows.

• The model's safeguards can be triggered excessively. As a result, even security reviews and penetration tests that we judge not to violate the model provider's terms, our own terms, or applicable laws may fail to deliver stable performance.
• Existing models (Claude Opus 4.8, and other models from Google and OpenAI) already show certain results with our harness. While we expect further performance gains from high-end models in the future, multi-stage attacks are realistically achievable in scenarios that do not require special 0-day (or complex 1-day) vulnerabilities.

Our View on the Performance of Existing Models​

The latter point in particular, that models up to and including Opus 4.8 have already reached a certain level, deserves attention.

The System Card for Claude Mythos 5 and Fable 5 and similar materials describe performance gains on benchmarks such as ExploitBench, OSS-Fuzz, and CyberGym. These generally have the exploitation of browsers and binaries in mind, and their evaluation of the ability to compromise web systems and cloud is limited.

The set of capabilities improved in Claude Mythos 5 can be imagined to be very important for organizations that face threats which exploit 0-day or highly complex N-day vulnerabilities.

On the other hand, the organizations that should assume threats of this intensity are limited. Typical system compromises start with people as the entry point, or with more basic mistakes (for example, unintentionally exposed admin consoles, weak passwords, well-known arbitrary code execution vectors such as React2Shell, unmaintained VPN appliances, unintentionally left secrets, and so on). The attack process after an attacker has completed initial intrusion also does not necessarily require complex 0-day or N-day vulnerabilities.

Assuming this minimal set of threats that most of our customers should be aware of, we believe that models prior to Claude Fable 5, such as Opus 4.8, are capable of sufficient simulated attacks. For example, our benchmark set includes scenarios that steal data on the cloud through multi-stage attacks with the simple configuration shown below. This is well within reach of pre-Opus 4.8 models combined with our harness.

Our Commitment to Safety​

If the model's safeguards are relaxed in the future, and once we have confirmed that we have safe safeguards and a harness appropriate to the model's performance, we will reconsider deploying Claude Fable 5.

In the use of AI for cybersecurity, the fact that benign and malicious use are two sides of the same coin is an unavoidable and important problem. Takumi byGMO and its provider, GMO Flatt Security, have kept this in mind and have applied basic controls such as organization authentication and ownership verification. We will continue to coordinate with model providers and with international efforts on AI safety, and we remain committed to the safe delivery of AI technology.

Availability of the AI Penetration Testing Feature​

The AI penetration testing feature, which we had said would be deployed and available within at most 5 business days after the general release of Mythos-class models, will be rolled out to customers in stages from Monday, June 15, after internal re-adjustment. To ensure stable delivery, the feature will be made available gradually.

Unlike the existing assessment features, the AI penetration testing feature has the AI attempt highly flexible attacks until it reaches a given goal (for example, stealing information within a specific cloud resource in scope). It is effective when you have already identified important information and components that would be damaging if compromised, through cloud asset inventory, threat modeling, and the like.

Contact​

As we roll out the AI penetration testing feature from June 15 onward, customers who would like priority access, or who are interested in the details of the feature, can contact their sales representative or reach out through our website.