trufflesecurity

An AI Attack Framework Got Into WorkOS's Sales Tool. It Held Customers' Slack Excerpts - Book: AI Agents Pocket Guide - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- WorkOS sells SSO, directory sync and audit controls to "thousands of SaaS companies", according to RuntimeWire. On November 2 it published a security bulletin about unauthorized access to an internal application its sales team uses. The attacker used "an AI-assisted offensive security framework to automate reconnaissance and exploitation attempts", the bulletin says. The contact list is the part people will skim past. The part to read twice is the third bullet of what that app held: "Summaries and excerpts from sales calls, support discussions, and customer Slack conversations" (WorkOS). What WorkOS says was in the sales tool The bulletin lists four kinds of data: - Business contact details from CRM systems: names, email addresses, phone numbers, job titles and company affiliations. - Account and relationship information, including customer account histories. - Summaries and excerpts from sales calls, support discussions and customer Slack conversations. - Operational metadata: product usage and connection or directory health information. WorkOS's notice to customers, reposted on Hacker News, adds detail the public bulletin leaves out. It dates detection to October 30 at 16:39 UTC, says the attacker reached an internal API used by sales and marketing tools, which gave access to Salesforce and Snowflake data, and says the attack was likely driven by ARTEX, with traffic from IP addresses in Hong Kong and China. It also says: "We have no evidence that your application data was accessed." A user of the site posted it there, not WorkOS, and WorkOS hasn't confirmed the detection time, the Salesforce and Snowflake detail or the IP locations on its own site. In the same thread, WorkOS CEO Michael Grinich wrote: "WorkOS's production systems are secure. No customer platform data was accessed" (Hacker News). He also disclosed the incident on X on November 2, and that post said ARTEX was involved, RuntimeWire reports. WorkOS says it disabled external access to the affected application, is reviewing access controls on its internal tools, and has hired an independent forensics and incident response firm. The review of affected records is ongoing, and WorkOS says it will contact affected customers directly (WorkOS). ARTEX, the framework named in the notice ARTEX is not new to defenders. Wiz described it on October 22 as "an open-source autonomous penetration testing framework" that a Chinese developer published on GitHub in July 2026. The developer made it closed-source on October 8, after the code had more than 12,000 forks. Google Threat Intelligence Group and Mandiant published their own analysis on October 30, the day WorkOS detected its incident. They describe ARTEX as "an autonomous, multi-agent LLM-driven pentesting and offensive command-and-control (C2) platform" that splits the attack lifecycle across "six specialized sub-agents" and calls "APIs from frontier and open source models". Google also lists variations, including a localized one called ScopeWeaver and a commercial version, ARTEX PRO. Google says the actor it tracks as UNC7228, which overlaps with Storm-0940, typically went "from their first compromised account to deep system access in around four hours and in one case as rapidly as 15 minutes" (Google Cloud). Individual execution sequences ran in bursts of 2 to 25 seconds. !A swarm of six small black robot agents with burnt-orange visors climbing over an open filing cabinet full of customer cards and chat bubbles, on a cream background ARTEX splits an intrusion across six sub-agents, per Google's analysis. WorkOS's customer notice says its incident was likely driven by it. Wiz said the ARTEX activity it saw overlaps with Microsoft's report on Storm-0940, which Wiz describes as "a Chinese-state aligned actor", and that it focused on IT and software vendors, especially identity providers. Neither Wiz nor Google mentions WorkOS, and WorkOS hasn't named an actor. Don't read the WorkOS incident as attributed to any group yet. The contact list is the smaller problem A list of names and emails gets you generic phishing. Call notes and Slack excerpts get you phishing that knows your integration, your account manager's name and the bug you reported last month. WorkOS's own guidance points the same way: contact details and past conversations can make fraudulent requests look legitimate, so "verify unexpected requests before sharing sensitive information or taking action" (WorkOS). For an identity vendor, the requests to watch are the ones that change who can sign in to your app, like a new SAML certificate or a "reconnect your directory" link. That's my reading of the risk, not something WorkOS has said. Either way, make any SSO config change through the dashboard you already log in to, never through a link in a message. Then look at what your team has pasted into shared vendor channels and support threads. Developers paste logs, config files and, sometimes, a key "just to reproduce it". WorkOS hasn't said whether any secrets were in the excerpts it lost, and its bulletin doesn't mention API keys. You don't need its answer to check your side. Export the shared channel or ticket history and scan it with TruffleHog: # Scan an exported channel or ticket history # for anything that looks like a credential. trufflehog filesystem ./vendor-channel-export Anything it finds that is still live gets rotated, whoever you shared it with. !A hook lifting a few chat bubbles out of a tall stack of conversation transcripts, with an envelope icon waiting below, black linework and burnt-orange accents on cream The bulletin lists summaries and excerpts of sales calls, support discussions and customer Slack conversations among the data involved. If you run internal tools, harden them like production The WorkOS target was a go-to-market app, not production. Internal go-to-market apps often get less hardening than the product itself. Wiz lists what ARTEX operators probed for: JavaScript source maps, runtime config files, Swagger/OpenAPI docs, password-reset endpoints and self-signup with disposable email addresses. The source-map check is one command: # Print the first bytes of the map, if it is served curl -s https://app.example.com/assets/main.js.map \ | head -c 40 If you get back JSON that opens with a "version" field, the map is public and anyone can read your original front-end source, routes included. Don't go by the status code alone: many single-page app hosts answer every unknown path with index.html and a 200. Swap in a real bundle path from your build output. Google's recommendations are short enough to paste into a ticket: - "Restrict all admin APIs, consoles & CI/CD to trusted networks" - "Migrate to short-lived workload credentials; eliminate secrets" - "Monitor unusual bursts of password resets, account creation, credential additions, permission changes, or other lifecycle activity." - Watch server egress to previously unseen destinations, especially webhook services. In the activity Google tracked, ARTEX posted results to rotating webhook.site URLs, 491 of them. What we still don't know WorkOS hasn't said how the attacker first got in. A commenter in the Hacker News thread asked about the initial vector and lateral movement, and that question had no answer there at the time of writing. There's no word yet on how many customers' records were in the tool, and the ARTEX attribution comes from WorkOS's own investigation, with no independent confirmation yet. The forensics firm's findings, and the direct notices WorkOS says are coming, should fill those gaps. If you're a WorkOS customer, watch for that direct notice. When it arrives, compare what it lists against what your team shared with the vendor, and rotate any credential that turns up in it. --- If this was useful ARTEX is an agent system pointed the wrong way: sub-agents, tool calls and model APIs chained toward a goal, at a speed no human operator keeps up with. The AI Agents Pocket Guide covers how those loops are built and where to put guardrails, which helps whether you're building agents or defending against one. I also build Hermes IDE, a desktop app for running coding agents side by side. Each agent uses its own CLI sign-in and Hermes never asks for your tokens. It's free, source-available, and on GitHub. Hermes IDE is not affiliated with Nous Research, WorkOS or any vendor named here. 

How to Run Regulated Apps in the Cloud: SOC 2, HIPAA, and PCI DSS Platforms, Data Residency With Failover, and a Compliance Checklist A compliant application platform gives you audited infrastructure controls, but compliance is shared: you still need your own controls for data classification, identity, secrets management, and logging. To keep data in one country with failover, run in at least two locations inside that country and ensure every replica, backup, and log stays there. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant, and it runs a workload only in the locations you choose across AWS, GCP, Azure, and your own servers. Disclosure: Control Plane publishes this guide. This is general guidance, not legal or audit advice. TL;DR - What platform compliance covers. SOC 2 Type II, HIPAA eligibility, and PCI DSS attestations apply to the platform’s services, not your application logic or data handling. - How to verify a platform ’s claims. Request the SOC 2 Type II report under NDA, the PCI DSS Attestation of Compliance, and a signed BAA. Check which services and regions are in scope. - Data residency with failover. Choose two or more locations inside the same country, run active-active or active-passive between them, and pin replicas, backups, logs, and keys to those locations. - The compliance checklist. Classify data, enforce region allow-lists with policy as code, manage secrets outside your codebase, isolate tenants, log everything immutably, and document AI data flows. - How Control Plane fits. On Control Plane, a workload runs only in the locations of Control Plane’s Global Virtual Cloud (GVC), a set of locations a workload runs across, so you control data residency by choosing locations. Workloads deploy active-active across every location in a GVC, and a global endpoint routes each request to the nearest healthy location. Which application platforms are SOC 2 Type II, HIPAA, and PCI DSS compliant? AWS, Google Cloud, and Azure each hold SOC 2 Type II reports and PCI DSS Level 1 service provider attestations, and each signs a BAA covering a published list of HIPAA-eligible services. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Its SOC 2 Type II audit was completed by Prescient Assurance, and its SOC 2 Type II report and PCI DSS Attestation of Compliance are available from support@controlplane.com, and its docs publish a PCI Responsibility Matrix. What each framework means for a platform buyer SOC 2 Type II is an attestation report from an independent CPA firm. The auditor tests whether a platform’s controls operated effectively over a review period, commonly three to twelve months. A Type I report covers only control design at a single point in time. Platforms renew the report each year, so check the period end date and ask for a bridge letter if it ended months ago. A badge on a marketing page shows none of the scope or exceptions, so ask for the report itself. HIPAA has no official certification program. The U.S. Department of Health and Human Services does not certify software or cloud platforms as “HIPAA compliant.” Instead, look for two things: a signed Business Associate Agreement (BAA), which sets out how the platform must protect electronic protected health information (ePHI), and a clear list of HIPAA-eligible services. Under the HITECH Act, a platform that handles ePHI as a business associate is also directly liable for complying with the HIPAA Security Rule. Any service not on that list should not touch ePHI. PCI DSS compliance is documented in an Attestation of Compliance (AoC), the official PCI Security Standards Council form summarizing the results of an assessment. Platforms that process, store, or transmit cardholder data are assessed as service providers. Card brands such as Visa and Mastercard classify a service provider as Level 1 when it handles more than 300,000 card transactions a year, and Level 1 requires an annual assessment by a Qualified Security Assessor (QSA) and a Report on Compliance. The AoC states which services and environments are in scope. How to verify a platform’s compliance 1. Request the SOC 2 Type II report under NDA. Read the auditor’s opinion, the description of the system boundary, and any exceptions noted. 2. Request the PCI DSS Attestation of Compliance. Confirm the service provider level and check which services and data center regions are covered. 3. Request a signed BAA before any ePHI touches the platform. Confirm the list of HIPAA-eligible services. 4. Check scope : which regions, which services, and which deployment models are included. A platform may be compliant in some regions but not others. AWS, Google Cloud, and Azure each publish compliance programs with lists of in-scope services. AWS maintains its compliance programs page, Google Cloud publishes its compliance offerings, and Azure documents its compliance offerings. Who owns which compliance controls, the platform or the customer? The table below maps common control areas to who typically owns them. Control Area| Typically Responsible| Evidence to Collect ---|---|--- Infrastructure security (host OS, hypervisor, physical)| Platform| SOC 2 Type II report, penetration test summaries Network segmentation and firewalls| Shared| Network architecture diagrams, firewall rule exports Identity and access management| Customer| SSO configuration, MFA enforcement logs, RBAC policies, access reviews Secrets management| Customer| Secrets manager configuration, rotation logs, proof secrets are not in code Data encryption (at rest and in transit)| Shared| Encryption configuration, key custody documentation, TLS certificates Logging and audit trails| Shared| Log retention policies, tamper-resistance proof, SIEM integration Application code security| Customer| SAST/DAST scan results, dependency vulnerability reports, change approvals Data classification| Customer| Data inventory, classification tags, handling procedures Backups and disaster recovery| Shared| Backup location confirmation, restoration test results, RTO/RPO evidence Incident response| Shared| Incident response plan, tabletop exercise records, notification procedures A platform’s audit reports cover the rows marked Platform and the platform’s part of the Shared rows. Rows marked Customer or Shared need your own controls and evidence. How do I keep customer data in a specific country while still having multi-region failover? Run the application in two or more locations inside the country, replicate data only between those locations, and keep every replica, backup, log, and key in-country. Traffic fails over between the in-country locations, never to a region abroad. Architecture options: - Active-active between two in-country locations removes failover delay, because each location already serves traffic, and a global load balancer routes requests to the nearest healthy one. - Active-passive keeps a standby location in-country that takes over during an outage. It costs less but introduces failover time. Databases in active-active. The application tier can run active-active, but most relational databases accept writes on one primary. Put the primary in one in-country location and a replica in the other, and send writes from both locations to the primary. Synchronous replication gives a recovery point objective (RPO) of zero, meaning no committed write is lost, at the cost of added write latency. In-country locations are usually close enough to keep that cost low. Asynchronous replication adds no write latency but can lose writes not yet copied when the primary fails. On failure, promote the replica and repoint the application. Use a quorum or fencing so two primaries never accept writes at once. To accept writes in every location, use a distributed SQL database such as CockroachDB, YugabyteDB, or Google Cloud Spanner, and keep all of its nodes in-country. For a deeper comparison of these patterns, see active-active vs. active-passive cost and architecture trade-offs. What to pin in-country: - Primary database and all replicas - Backups and snapshots - Object storage buckets - Application logs and audit logs - Encryption keys - Cache layers What to check: - Where does the platform’s support staff access data from? - Where do telemetry and monitoring data flow? - Where does TLS terminate? Global load balancers and CDNs can decrypt requests at edge sites outside the country. - Where do managed AI APIs send prompts and responses for processing? - Does the platform offer contractual commitments on data location? Where can I find a cloud provider that keeps my data in one country to reduce risk? AWS, Google Cloud, and Azure each run two or more regions in the United States, Canada, Australia, Japan, and India, so one provider can cover in-country failover in those countries. Not every country has two cloud regions from a single provider. In those cases, combining regions from multiple providers, or adding your own data center, may be the only viable in-country option. A detailed breakdown of provider coverage by country is available in best cloud providers for data sovereignty in 2026. For architectural patterns, see sovereign cloud architecture for data residency compliance. What practical controls ensure data residency and sovereignty in a multi-cloud infrastructure? - Region allow-lists enforced by policy. Each major cloud has a native mechanism: AWS Service Control Policies with aws:RequestedRegion conditions (with exemptions for global services such as IAM), Azure Policy’s built-in Allowed locations policy, and the Google Cloud resource locations organization policy constraint. - Data classification and tagging. Tag every resource with its data classification (e.g., data-class: phi, data-class: pci). Use tags to trigger policy enforcement and to generate audit reports. - Encryption with keys held in-region. Store encryption keys in the same jurisdiction as the data they protect. Cross-border key storage can undermine sovereignty even if the ciphertext stays in-country. - Egress controls. Block or alert on data transfers to regions outside the approved list. Use VPC flow logs, firewall rules, and DLP inspection at egress points. - Residency-aware backups. Explicitly configure backup destinations. Some services copy backups or geo-redundant replicas to a second region by default or with a single setting, and that region is not always in the same country. For example, Azure geo-redundant storage replicates to the paired region, and Brazil South is paired with South Central US. Multi-region storage locations such as Google Cloud’s EU or US buckets span several countries. - Logging location. Route logs to a logging service or bucket pinned to an approved region. If you use a third-party logging provider, confirm where they store and process your data. - Regular audits. Periodically scan for resources created outside approved regions. Automated compliance scanners can flag drift before it becomes an audit finding. What cloud compliance checklist should I follow when migrating a regulated application to AI infrastructure? AI workloads introduce new compliance surfaces. Prompts, model outputs, training data, and vector store contents can all contain regulated data. Follow this checklist: 1. Classify data before it reaches a model. Determine whether inputs contain ePHI, cardholder data, PII, or other regulated categories. Apply classification before inference, not after. 2. Decide what can go to third-party model APIs. If you use external APIs for inference, confirm the provider’s compliance posture, sign the appropriate agreements (BAA, DPA), and understand where prompts and responses are processed and stored. Confirm in writing that prompts are not used for training and how long the provider keeps them. 3. Prefer self-hosted or in-region inference for regulated data. Running models on infrastructure you control, within approved regions, keeps regulated data off third-party networks. 4. Log prompts and outputs with redaction. Maintain audit logs of what was sent to a model and what it returned. Redact or tokenize regulated fields before logging. 5. Apply access control to models and vector stores. Treat model endpoints and vector databases as regulated data stores. Enforce RBAC, authentication, and network segmentation. 6. Keep training and fine-tuning data in-region. If you fine-tune models on regulated data, the training data, checkpoints, and resulting model weights must stay within approved jurisdictions. 7. Document data flows for auditors. Create a data flow diagram that shows how regulated data moves through your AI pipeline: ingestion, preprocessing, inference, post-processing, storage, and deletion. Auditors will ask for this. 8. Plan for deletion. Embeddings and fine-tuned weights derived from personal data must be deletable when a data subject asks for erasure, so record which data each one came from. What are the best practices for secrets management in IaC pipelines to meet cloud compliance requirements? Secrets in infrastructure-as-code pipelines are a frequent audit finding and a common attack vector. - No secrets in code, state files, or CI logs. Credentials leaked in repositories are a common way attackers get cloud access. Terraform writes values read through data sources into state; Terraform 1.10 added ephemeral resources and 1.11 added write-only arguments to keep secrets out of state and plan files. - Use a secrets manager, referenced by name. Store secrets in a dedicated service such as AWS Secrets Manager, Google Cloud Secret Manager, or Azure Key Vault, or in HashiCorp Vault. IaC templates should reference secret names, never values. - Short-lived credentials through workload identity federation. Replace static API keys with short-lived federated tokens that expire automatically, typically within an hour. AWS, GCP, and Azure all support workload identity federation natively. - Least-privilege pipeline roles. The CI/CD service account should have only the permissions needed for the current deployment. Separate roles for plan and apply stages. - Rotation. Automate rotation on a defined schedule, and rotate immediately after a suspected exposure or when someone with access leaves. Log every rotation. - Secret scanning in CI. Run tools like Gitleaks or TruffleHog in your CI pipeline to catch secrets before they merge. - Encrypted and access-controlled IaC state. Terraform and Pulumi state files can contain sensitive values. Encrypt state at rest, restrict access to the state backend, and audit who reads it. How should I structure governance and policy as code for compliant multi cloud infrastructure using IaC? Policy as code turns compliance rules into enforceable, version-controlled, auditable artifacts. Structure it in layers: Preventive guardrails at the account or organization level. These are the broadest controls. Service Control Policies in AWS, Organization Policies in Google Cloud, and Azure Policy assignments at the management group level prevent non-compliant resources from being created in the first place. Policy checks in CI before apply. Before any IaC change reaches production, validate it against your compliance rules. Open Policy Agent (OPA) is a widely adopted open-source engine for this purpose. Evaluate the JSON output of terraform plan with OPA through a tool such as Conftest, or use Pulumi CrossGuard policy packs with pulumi preview, and fail the pipeline on violations. In Kubernetes, OPA Gatekeeper or Kyverno applies the same rules at admission time. Runtime detection. Even with preventive controls, configuration drift happens. Use runtime scanners to detect resources that have drifted from their compliant state and alert or auto-remediate. Evidence collection for audits. Every policy evaluation, pass or fail, should produce a log entry. These logs become audit evidence showing that controls were in place and operating continuously. Examples of rules to codify: - Allowed deployment regions (for example, only the regions inside the country your data must stay in) - Required encryption on all storage resources - Required classification tags on every resource - No public access on storage buckets or object stores - MFA required for privileged roles What cloud solutions offer multi tenant protection against cross tenant data breaches? Cloud platforms separate tenants at three layers: separate accounts or projects (AWS accounts, Google Cloud projects, Azure subscriptions), compute isolation (separate clusters or microVM sandboxes such as Kata Containers), and data isolation (separate databases and per-tenant encryption keys). Tenant isolation models Model| Layer| Isolation| What tenants still share ---|---|---|--- Separate accounts or projects| All layers| Highest| Only organization-level billing and policy Separate clusters in one account| Compute| High| Cloud IAM, network, and account quotas Separate namespaces in one cluster| Compute| Low to moderate| Kernel, nodes, and cluster control plane; relies on network policies, RBAC, quotas, and pod security Separate database instances| Data| High| Network and admin credentials Separate databases or schemas on one instance| Data| Moderate| Database engine, memory, and admin accounts Row-level security on shared tables| Data| Lowest| Everything; one missing tenant context or a role that bypasses RLS exposes other tenants Choose a compute model and a data model separately. A common pattern is separate accounts for the most sensitive tenants and shared clusters with separate databases for the rest. How do I design AI infrastructure for cloud compliance using BYOK and tenant data segregation? In this context, BYOK (bring your own key) means encrypting data with keys you control, generated or imported into a cloud key management service, instead of provider-managed keys. Tenant isolation and per-tenant encryption are the two pillars of preventing cross-tenant data exposure. Per-tenant encryption keys Store each tenant’s encryption key in a cloud KMS (such as AWS KMS, Google Cloud KMS, or Azure Key Vault). The application references the tenant’s key ID when encrypting or decrypting that tenant’s data. If one tenant’s key is compromised, only that tenant’s data is exposed. Disabling or deleting a tenant’s key makes their data unreadable, which supports offboarding and deletion requests, and KMS logs show every use of each tenant’s key. Scope the application’s decrypt permission per tenant, or one compromised service can still use every key. Tenant separation in AI workloads Vector stores and model caches introduce new cross-tenant risks. If multiple tenants share a vector database, queries from one tenant could surface embeddings from another. Mitigations include: - Namespace or collection-level separation within the vector store - Tenant-scoped query filters enforced at the application layer - Separate model inference endpoints per tenant for the most sensitive workloads - Scoping prompt caches and response caches to one tenant. Inference servers that reuse the KV cache for shared prompt prefixes, and semantic caches that return a stored answer for a similar prompt, can leak data or timing signals across tenants. Add the tenant ID to the cache key or disable cross-tenant cache sharing. How Control Plane approaches regulated workloads Control Plane is the unbreakable platform for production workloads. It combines any cloud, neocloud, bare metal, and your own servers into what Control Plane calls a Global Virtual Cloud (GVC), and teams run it in a single region, a single cloud, or across clouds. Control Plane handles Day 2 operations for you, including autoscaling, right-sizing, built-in observability, and security, with no Kubernetes cluster you have to operate. Compliance posture. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. These controls and the evidence they produce support your compliance, though they do not make you compliant on their own. Data residency through location selection. A workload runs only in the locations of its GVC, which can include AWS, GCP, and Azure regions, Kubernetes clusters you already run, and servers in your own data center or from bare-metal and GPU providers. Control Plane Managed Kubernetes (MK8s) joins those servers into a cluster that Control Plane runs for you as a location. You can keep two or more locations inside one country, including combinations of providers, so the GVC’s location list acts as the region allow-list for that workload. Two in-country locations can also meet the 99.999% SLA condition below. Platform data is handled separately: org secrets are encrypted with envelope encryption and held in cloud HSMs across multiple providers, and logs are aggregated by Control Plane (30-day default retention) and can also be shipped to destinations you control, such as an Amazon S3 bucket or CloudWatch in your chosen region. Active-active failover. A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers. For strategies on surviving a single-region outage, see how to keep your app online during an AWS region outage. Security defaults. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS, with each workload’s client certificate rotated every hour. All data is encrypted at rest and in transit. Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane Sandboxes, isolated environments for AI coding agents and untrusted code, run in dedicated Kata Containers microVMs. Secrets and identity. Control Plane’s built-in secrets management lets workloads reference a secret as cpln://secret/NAME once their identity is granted the reveal permission, so secret values stay out of code and images. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code. Audit trail. Every action, whether made through the console, CLI, Terraform, Pulumi, or AI agents using the Control Plane MCP server, is recorded in a tamper-proof audit trail. Your own workloads can write application events to the same audit trail through a custom audit context. Policy and IaC. Control Plane policies are org-scoped and grant fine-grained permissions on every resource type to users, groups, service accounts, and workload identities. Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run. Cost. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. SAFE Health, a connected-diagnostics platform working with Mayo Clinic, migrated 8 environments from AWS to Control Plane and cut its AWS spend 75 percent. For teams looking to simplify multi-cloud operations or consolidate existing infrastructure, see how to consolidate multiple clouds into one platform. For a comparison of managed platform services versus building your own portability layer, see managed services vs. portability and cloud lock-in. FAQ Does a SOC 2 Type II report mean a platform is secure? No. A SOC 2 Type II report shows that an independent auditor tested specific controls and found they operated effectively over a defined period. Read the report’s scope, exceptions, and complementary user entity controls to understand what the platform covers and what you must handle. Is there an official HIPAA certification for cloud platforms? No. The U.S. Department of Health and Human Services does not certify cloud platforms as HIPAA compliant. Look for a signed Business Associate Agreement and a published list of HIPAA-eligible services. The BAA sets the platform’s contractual obligations for safeguarding ePHI, and under HIPAA a business associate is also directly liable for certain requirements, including the Security Rule. What is the difference between PCI DSS Level 1 and other levels? Level 1 is the top tier for service providers. Visa and Mastercard assign it to service providers that handle more than 300,000 card transactions a year, and it requires an annual assessment by a Qualified Security Assessor, who issues a Report on Compliance (ROC) and an Attestation of Compliance (AoC). Level 2 service providers can self-assess with Self-Assessment Questionnaire D. Ask any provider for its responsibility matrix, which PCI DSS v4.0 requirement 12.9.2 obliges it to provide on request. Can I achieve multi-region failover while keeping all data in one country? Yes, if the country has two or more available cloud regions or data center locations. Run active-active or active-passive between them and pin all replicas, backups, logs, and encryption keys to those locations. If a single provider lacks two in-country regions, combine providers or add your own data center. How do I prevent secrets from leaking in IaC pipelines? Store secrets in a dedicated secrets manager and reference them by name in your IaC templates. Use short-lived credentials through workload identity federation, run secret-scanning tools in CI, encrypt your IaC state files, and restrict access to the state backend. What is the shared responsibility model in cloud compliance? The platform is responsible for infrastructure-level controls such as physical security, hypervisor patching, and network fabric. You are responsible for identity and access management, secrets, application code security, and data classification. Network segmentation, encryption, logging, backups, and incident response are shared. How should I handle regulated data in AI inference pipelines? Classify data before it reaches a model. Use self-hosted or in-region inference for regulated data. Log prompts and outputs with redaction of sensitive fields. Apply access control to model endpoints and vector stores. Document the full data flow for auditors. Does Control Plane make my application compliant? No. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant and provides audited controls and evidence that support your compliance, but your application still needs its own controls for data classification, identity, secrets, application security, and logging. Can Control Plane keep my workload in a single cloud? Yes. Many teams run Control Plane in a single cloud for its Day 2 operations and security defaults. A GVC can contain locations from a single provider, and two regions of one cloud qualify for the 99.999% SLA when a workload runs at least two replicas in those two locations. How does Control Plane handle workload isolation? Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane Sandboxes run in dedicated Kata Containers microVMs. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS. See how Control Plane runs regulated workloads. Talk to the Control Plane team or sign up free --- Originally published on the Control Plane blog.

DevSecOps для тех, кто не безопасник: как встроить SAST, SCA и поиск секретов в CI/CD Типичная сцена из жизни команды разработки: тимлиду или DevOps-инженеру прилетает задача от руководства — «нужно прикрутить безопасность к пайплайну». Вы не безопасник, но задача стоит, и ваш минимум: чтобы не пускало уязвимости в прод. Обычный и логичный путь — взять популярный сканер (Trivy, SonarQube, Semgrep), воткнуть его новым шагом в пайплайн GitLab CI или GitHub Actions с дефолтным конфигом и запустить на мастере. Но спустя десять минут пайплайн с треском падает. Сканеры с гордостью выдают 480 предупреждений: от устаревшей минорной библиотеки пятилетней давности в глубине node_modules до гипотетической уязвимости в тестовом скрипте, который вообще не попадёт в прод. Реакция команды предсказуема: через неделю постоянных ложных блокировок разработчики либо прописывают allow_failure: true, либо аккуратно забивают на алерты. Безопаснее не стало, релизы замедлились, а при упоминании «DevSecOps» все только раздражаются. Проблема не в инструментах, а в подходе. Встроить безопасность в CI/CD — это настроить гигиенический минимум, который отлавливает реальные угрозы и при этом не тормозит поставку фич. Чтобы практики были из реальной работы, а не из теории, материал проверил практикующий безопасник: Нияз КашаповТимлид команды AppSec в Циане, дипломный руководитель на курсе Нетологии «Специалист по информационной безопасности» TL;DRПроблема DevSecOps не в инструментах, а в подходе: сканер «из коробки» заваливает пайплайн сотнями ложных срабатываний, и команда перестаёт их читать — безопаснее не становится. Гигиенический минимум — три слоя в CI/CD, каждый на своём этапе: поиск секретов (Gitleaks), проверка зависимостей (SCA, Trivy) и базовый SAST (Semgrep). Главный враг — шум, а не отсутствие проверок. Его снимают Baseline по старому коду, тюнинг правил и процесс триажа; сборку блокируем только на проверенных находках. Проверки делим на жёсткие (валят релиз лишь на критичном с патчем и на открытых секретах) и мягкие (просто сигналят в PR, не блокируя). Внедряем поэтапно: режим аудита → фиксация Baseline → блокировки. Базовый контур собирается за несколько дней на опенсорс-инструментах. Почему сканеры «из коробки» ломают процесс Если запустить условный Trivy, Semgrep или SonarQube на действующем проекте без предварительной фильтрации, вы почти наверняка получите не реальную картину защищённости, а лавину из сотен ложных предупреждений. Сканеры безопасности вендоры проектируют по принципу Maximum Coverage — «лучше перебдеть, чем недобдеть». Без настройки многие инструменты оптимизированы скорее на полноту обнаружения, чем на точность. Разберём четыре главные причины, почему дефолтный вывод сканеров вызывает у инженеров желание выключить всё, что можно: 1. Отсутствие понимания досягаемости (Reachability) Инструмент анализа состава ПО (SCA) анализирует файл манифеста (например, package-lock.json, go.sum или requirements.txt) и сверяет версии зависимостей с базами известных уязвимостей (CVE). Как это работает: сканер находит критичную уязвимость в транзитивной зависимости и с пометкой CRITICAL блокирует билд. Реальность: ваша программа использует из этой библиотеки всего одну утилитарную функцию (например, форматирование даты), а уязвимый код даже не импортируется и никогда не исполняется. Для вашего сервиса эта сработка нерелевантна: уязвимый код недостижим. Но из-за отметки сканера пайплайн падает. 2. Контекстная слепота Автоматический инструмент не знает, где и как исполняется код. Для него код публичного платёжного шлюза и внутренний CLI-скрипт для генерации тестовых данных одинаково критичны. Пример: сканер находит зашитый API-ключ в файле tests/fixtures/mock_data.go и помечает его как утечку секрета высокого риска. Инженер вынужден тратить время, чтобы объяснить инструменту: это фейковый токен для юнит-тестов, он не ведёт в боевую инфраструктуру. 3. Тупик транзитивных зависимостей По данным отчёта OSSRA (Black Duck, 2025), более 70% типового приложения — открытый код: своего кода в сборке лишь малая часть, остальное тянут сторонние библиотеки и их «дочки» — транзитивные зависимости. Ловушка: сканер сообщает, что библиотека A использует библиотеку B, в которой есть CVE. При этом мейнтейнеры библиотеки A ещё не выпустили патч с обновлением. Вы попали в тупик: обновить B вручную нельзя (сломается совместимость), патча для A нет, пайплайн горит красным. 4. Усталость от алертов — «синдром мальчика и волков» Когда разработчик регулярно видит десятки HIGH- и CRITICAL-алертов, он постепенно перестаёт воспринимать их как одинаково срочные. Если критично всё — значит, не критично ничего. Инженеры перестают вчитываться в алерты и начинают искать пути обхода: глобально подавляют варнинги или просто привыкают игнорировать красный крестик в CI. В этот момент действительно опасная уязвимость (например, случайно забытый токен от прода) беспрепятственно уходит в репозиторий. Главный вывод: задача инженерной команды при внедрении DevSecOps — заставить сканер искать уязвимости более фокусно, не создавая множества ложных срабатываний. Автоматика должна останавливать сборку только тогда, когда обнаружена понятная, воспроизводимая и опасная угроза. Минимальный гигиенический стек: три обязательных слоя Чтобы пайплайн оставался быстрым и не раздражал команду, не нужно внедрять десяток сложных сканеров одновременно. По опыту эксперта, в большинстве случаев для защиты продукта достаточно трёх базовых слоёв. Нияз Кашапов Тимлид команды AppSec в Циане Цифра в 80% — из опыта работы в различных компаниях. Рассматриваемые инструменты интегрировать проще всего, и они дают результат достаточно дёшево и быстро. Такие практики, как DAST и fuzzing, требуют глубокого анализа окружения (стек, библиотеки, стенды) и настройки под конкретный кейс. Кроме того, финансово эти практики очень дорогие и не такие эффективные. Каждый из них решает свою конкретную задачу, запускается на определённом этапе CI/CD и использует лёгкие, проверенные опенсорс-инструменты: [ Git Push / PR ] | ├── 1. Secret Scanning (Gitleaks) ──> Блокирует сразу (< 2 сек) ├── 2. SCA / Dependencies (Trivy) ──> Сканирует lock-файл (10-30 сек) └── 3. Lightweight SAST (Semgrep) ──> Проверяет diff (5-20 сек)sourcecraft.dev Слой 1. Поиск секретов. Secret Scanning Утечка API-ключей, токенов облачных провайдеров (например, AWS или Yandex Cloud) или паролей от баз данных — одна из самых массовых и недооценённых проблем. Бот-сканеры злоумышленников находят забытый токен в публичном Git легко, а живут такие секреты годами. В исследовании Truffle Security нашли 543 699 действующих секретов в публичных репозиториях: медианный возраст — 784 дня, и к моменту проверки они всё ещё работали. С корпоративным Git всё сложнее, но не забываем про внутренних нарушителей и ошибки, когда приватные репо неожиданно сливаются в публичные сервисы. Как работает: ищет токены, приватные ключи, пароли и сертификаты с помощью регулярок и анализа энтропии строк. Чем сканировать: Gitleaks или TruffleHog. При необходимости набор правил можно расширить дополнительными базами паттернов, например Secrets Patterns DB. Когда запускать: на самых ранних этапах — в идеальном мире как pre-commit хук на машине разработчика, либо как самый первый шаг при открытии PR. Почему это работает: у правильно настроенного поиска секретов обычно относительно мало ложных срабатываний. При обнаружении потенциально реального ключа проверку лучше блокировать до триажа. Золотое правило — если секрет попал в Git-историю, он считается скомпрометированным. Его нельзя просто перекрыть новым коммитом — токен нужно немедленно отозвать и сгенерировать заново. Слой 2. Проверка зависимостей. SCA — Software Composition Analysis Современная разработка — это сборка приложения из сторонних пакетов. Вы пишете 500 строк своего кода, но под капотом подтягиваете 200 МБ сторонних npm, pip или go модулей. Как работает: парсит lock-файлы (package-lock.json, poetry.lock, go.sum, Cargo.lock) и сверяет версии используемых библиотек со свежими базами уязвимостей (CVE). Чем сканировать: Trivy, OSV-Scanner, Dependency-Check. Для постоянного мониторинга зависимостей — Dependency-Track. Когда запускать: на этапе сборки или проверки PR. Как снизить шум: 1. Сканируйте только манифесты и lock-файлы, а не всю файловую систему контейнера на первом этапе. 2. Включите флаг --ignore-unfixed — если для библиотеки ещё нет исправления, падающий пайплайн вам не поможет, вы только заблокируете релиз. Нияз Кашапов Тимлид команды AppSec в Циане Использование --ignore-unfixed помогает сфокусироваться на актуальных уязвимостях, несущих риски, которые можно закрыть обновлением. Однако не стоит игнорировать „unfixed“-уязвимости. Некоторые из них можно закрыть конфигурацией приложения или другими митигирующими действиями. В процессе стоит сделать акцент на рассмотрении и анализе критичных сработок (с оценкой 8+ по CVSS). 3. Фильтруйте по порогу: падать только на CRITICAL и HIGH. 4. Настройте правила исключений. Если уязвимость в вашей системе недостижима, внесите её в исключения через конфигурационные файлы инструмента. Слой 3. Базовый статический анализ. SAST Статический анализ собственного кода часто путают со стандартными линтерами (ESLint, golangci-lint). Обычный линтер следит за форматированием и неиспользуемыми переменными, а SAST ищет шаблоны опасного поведения в логике приложения. Как работает: находит SQL-инъекции, небезопасную десериализацию, жёстко зашитые IP-адреса, отсутствие проверки прав и использование слабых криптографических функций. Чем сканировать: Semgrep (CE — для быстрых проверок; Pro Engine — для межфайлового анализа), Bandit (для Python), gosec (для Go), SpotBugs с плагином FindSecBugs — для Java. Для Node.js можно использовать NodeSecure CLI — он анализирует зависимости и ищет подозрительные паттерны в пакетах (supply-chain-слой), дополняя классический SAST. Когда запускать: при создании или обновлении PR. Как снизить количество ложных срабатываний: → Выбрать наиболее эффективные правила для своего стека. Можно использовать готовые проверенные наборы правил, например p/security-audit или p/owasp-top-ten в Semgrep. → При первичном анализе просканировать проект целиком. Это поможет проверить, как работают выбранные правила, и отключить те, которые дают слишком много ложных срабатываний. → Для постоянных проверок сканировать изменения в PR. После первоначальной настройки нет необходимости каждый раз проверять весь проект целиком — достаточно анализировать изменённый код. Сводная матрица слоёв Слой Инструмент Ориентировочное время работы (на среднем сервисе) Что считается блокером релиза? Secrets Gitleaks < 2 секунд Любой найденный валидный секрет или токен SCA Trivy 10–30 секунд CRITICAL или HIGH уязвимости с существующим патчем SAST Semgrep или SAST-инструмент под конкретный стек технологий (bandit, gosec, brakeman) 5–20 секунд (на diff) 2–10 минут (на полный скан) Подтверждённые критические паттерны (например, SQLi) Мы собрали гигиенический минимум — секреты, SCA и базовый SAST. Полный DevSecOps шире: DAST, IAST, моделирование угроз, защита контейнеров. DevSecOps за 5 месяцев с дипломом НИУ ВШЭ Разберёте SAST, SCA, DAST, IAST, OWASP Top 10 и моделирование угроз, выстроите защиту на всех этапах разработки. Нужна база в коммерческой разработке. Посмотреть программу → Quality Gates: разделение на «жёсткие» и «мягкие» проверки Главная ошибка при внедрении DevSecOps — настроить сканер так, чтобы он валил сборку при любом найденном недочёте. Если ваш CI/CD превратится в блокиратор по каждому варнингу, разработчики быстро найдут способ обойти проверки. Решение — разделение проверок на два типа: блокирующие (Hard Gates) и неблокирующие (Soft Gates). Параметр Блокирующие Неблокирующие Поведение CI Завершает проверку с ошибкой (exit 1). Если успешный CI настроен как обязательное условие, PR нельзя будет смёржить. Пропускает сборку (exit 0 / allow_failure: true). Результат проверки можно вывести в PR, дашборд или отправить уведомлением. Что проверяет Критические уязвимости, где риски очевидны, а исправление однозначно. Потенциальные проблемы, требующие ручного анализа (триажа), или технический долг. Примеры триггеров • Найден открытый секрет или токен в коде. • CRITICAL уязвимость в зависимости, для которой есть патч. В идеальном мире — уязвимость, у которой есть exploit или подтверждение эксплуатируемости. • Прямая SQL-инъекция в новом коде (diff). • HIGH или MEDIUM уязвимости без готового патча. • Устаревший SSL или TLS протокол в конфиге. • Уязвимости в старом (legacy) коде, не затронутом в PR. Куда идёт сигнал Напрямую в интерфейс PR (красный крестик). В комментарий к PR, дашборд безопасности или таск-трекер. Пошаговый план внедрения Quality Gates Чтобы команда не саботировала внедрение, переходить к блокировкам нужно в три этапа: Этап 1. Режим аудита 2–3 недели. Shadow mode Все сканеры запускаются с параметром allow_failure: true (или continue-on-error: true). Пайплайн никогда не падает. Результаты публикуются в виде отчётов или комментариев к PR. Цель: собрать статистику, оценить реальный уровень шума и отлавливать ложные срабатывания до того, как они начнут мешать разработке. Нияз Кашапов Тимлид команды AppSec в Циане Держите режим аудита (audit mode) минимум один полноценный релизный цикл или пока не получите достаточную выборку срабатываний (findings) для настройки правил. Этап 2. Фиксация Baseline или базовой линии У каждого проекта есть накопившийся технический долг. Если сканер находит 200 старых уязвимостей в коде трёхлетней давности, разработчик не должен чинить их заодно с вёрсткой новой кнопки. Для этого используют Baseline (есть в Semgrep, SonarQube). Фиксируется текущий «слепок» всех найденных проблем проекта. Сканер не делает акцент на старых уязвимостях и начинает показывать уязвимости только в новом коде (New Issues / Diff Scanning). Нияз Кашапов Тимлид команды AppSec в Циане Сканирование diff полезно, когда CI должен быть быстрым и важно посмотреть написанный код. Однако хорошей практикой является постоянное обновление находок полными сканированиями по ночам или в выходные. Это позволяет смотреть код комплексно, особенно если инструменты поддерживают AST или taint-анализ. Правило для команды: «Старый долг разбираем планово, но новый код пишем чистым». Этап 3. Включение Hard Gates на критические триггеры Только после фиксации Baseline и отладки правил включаются блокировки. Начните с жёсткого минимума: Gitleaks: настроить блокирующую проверку новых секретов — перед коммитом или при проверке PR. Trivy: настроить проверку так, чтобы PR блокировался при обнаружении новых CRITICAL-уязвимостей, для которых есть исправление. Например, использовать --severity CRITICAL --ignore-unfixed --exit-code 1. Впоследствии gate настроить на блокировку и HIGH уязвимостей. Semgrep: заблокировать PR при критических паттернах в изменённых файлах. Важный момент: блокировка в CI — это стоп-сигнал, но не окончательный запрет на релиз. Команда разработки разбирает критичные находки, требующие срочного внимания, и проводит триаж. По его результатам даже находка уровня CRITICAL может оказаться ложным срабатыванием. Процесс триажа: как обрабатывать алерты без хаоса Даже самый отточенный сканер время от времени будет вызывать ложные срабатывания. Если в команде не выстроена понятная процедура анализа и подавления таких алертов, пайплайн быстро обрастёт «костылями» в виде глобальных игноров, а сканирование потеряет смысл. Процесс первичной оценки и сортировки находок называется триажем (Triage). Когда сканер подсвечивает строку кода или зависимость, у инженера есть три основных сценария действий: True Positive: сканер прав. Ошибка исправляется прямо в ветке разработки до мёрджа. Если уязвимость найдена в legacy-коде в рамках фонового сканирования — заводится задача в таск-трекере с приоритетом в зависимости от критичности. False Positive: инструмент ошибся из-за недостатка контекста (например, принял тестовый хэш за API-ключ). Алерт нужно подавить так, чтобы он больше никогда не беспокоил команду при повторных сборках. Acceptable Risk: уязвимость реальна, но её эксплуатация затруднена или имеет нивелируемый импакт (например, уязвимый модуль используется только во внутреннем CLI-инструменте без доступа к сети). Команда принимает риск, фиксирует его в реестре рисков и задаёт таймаут (например, пересмотреть через 3 месяца). Нияз Кашапов Тимлид команды AppSec в Циане Конечно же, сценариев больше. Некоторые сработки могут потребовать больше времени на исследование. Какие-то сложно оценить по критичности. Часть рисков может быть снижена или размазана по другим сервисам. А если мы начнём рассматривать полный флоу, то обязательно необходимо посмотреть, не была ли уязвимость поэксплуатирована и стоит ли заводить инцидент ИБ. Подавление алертов. Suppression Hygiene Очень опасный сценарий — когда разработчики начинают массово вставлять комментарии вроде # nosec или // ignore без разбора, просто чтобы проскочить CI. Чтобы сохранить прозрачность и контроль, используют жёсткие правила: 1. Локальные игноры (Inline / Code-level) Подходят для SAST (Semgrep) и поиска секретов (Gitleaks). Плохо: apiKey = "12345-test-key" # nosec commitHash = md5(commit) # nosec sourcecraft.dev Хорошо (с обязательным контекстом): apiKey = "12345-test-key" # gitleaks:allow -- Mock token for local unit tests only, see SEC-402sourcecraft.dev 2. Конфигурационные файлы (Project-level) Подходят для SCA и других проверок. Для разных инструментов используются свои файлы исключений — например, .trivyignore.yaml для Trivy или .semgrepignore для Semgrep. Каждое исключение должно сопровождаться комментарием с указанием причины и ссылки на задачу, а сам файл подключают к Trivy флагом --ignorefile ./.trivyignore.yaml: .trivyignore.yaml CVE-2023-XXXXX: Уязвимость в генераторе PDF. Сервис изолирован (DMZ), прямого пользовательского ввода нет. Временный риск до релиза v2.4 (01.09.2026) Ticket: APP-1092 | Date: 2026-08-11 vulnerabilities: - id: CVE-2023-XXXXX paths: - "usr/lib/libssl.so" statement: "Уязвимость в генераторе PDF. Сервис изолирован в DMZ" expired_at: 2026-09-01 sourcecraft.dev Кто должен проводить триаж Распространённая ошибка — заставлять отдел безопасности (AppSec) разгребать каждый алерт из CI/CD. Это создаёт узкое горлышко и задерживает релизы. Первая линия — автор кода или тимлид. Разработчик лучше всех знает контекст своего PR. Он должен уметь самостоятельно обосновать и прописать инлайн-игнор для очевидного ложного срабатывания. Вторая линия — Security Champion или DevOps. Инженер внутри команды разработки, прошедший минимальный инструктаж по безопасности. Он помогает оценить спорные находки и правильно оформить принятие риска. Третья линия — эксперты по безопасности. Подключаются только к сложным архитектурным вопросам, массовым уязвимостям нулевого дня (0-day) или спорным ситуациям при блокировке критических релизов. С чего начать: минимальный план внедрения Внедрение безопасности в CI/CD не требует месяца настройки или покупки дорогих платформ. Соберите рабочий контур за три шага — по одному слою в день: День 1. Внедрите поиск секретов (Gitleaks). Поставьте сканирование секретов первым шагом в PR. Настройте блокировку сборки при нахождении валидных ключей. Ложных срабатываний будет минимум, а эффект от предотвращения утечек — уже очень заметный. День 2. Настройте проверку зависимостей (Trivy). Проверьте сканером только lock-файлы (package-lock.json, poetry.lock и так далее). Включите флаги --ignore-unfixed и фильтр по CRITICAL. День 3. Добавьте лёгкий SAST (исходя из вашего стека технологий). Подключите базовый набор правил (OWASP Top 10) и ограничьте сканирование только изменёнными файлами (diff) в PR. Когда три слоя собраны, не включайте блокировки сразу. Переводите пайплайн в блокирующий режим по фазам из раздела «Пошаговый план внедрения Quality Gates»: сначала режим аудита, затем Baseline, и только потом Hard Gates на критичное. По подтверждённым находкам заводите задачи и дотачивайте правила. Чек-лист: готовность вашего MVP DevSecOps Пройдитесь по этому списку, чтобы убедиться, что собранный пайплайн помогает команде, а не превращается в очередной источник раздражения: ▢ Защита от утечек. Сканер секретов (Gitleaks / TruffleHog) проверяет каждый PR и блокирует сборку при нахождении реальных секретов. ▢ Фокус на lock-файлах. Проверка зависимостей (SCA) анализирует только манифесты/lock-файлы, а не проверяет весь контейнер целиком на этапе разработки. ▢ Игнорирование патчей-фантомов. Для проверки зависимостей включён флаг --ignore-unfixed (не блокировать сборку из-за CVE без существующего исправления). ▢ Сканирование только кода, затрагивающего функциональность. SAST-сканер проверяет не весь монорепозиторий, а только код, связанный с изменяемой функциональностью. ▢ Зафиксирован Baseline. Старый технический долг вынесен в отдельный список или слепок и не блокирует текущую работу над новыми фичами. ▢ Чёткие Quality Gates. Жёсткие блокировки (Hard Gates) настроены только на CRITICAL проблемы с готовыми исправлениями и поиск секретов. ▢ Регламент обработки срабатываний. В команде есть стандарт для ложных срабатываний — с обязательным указанием причины и ссылки на тикет (# gitleaks:allow -- Mock token, see SEC-101). ▢ Скорость пайплайна. Для монолитов и крупных сервисов нормой считается от 1 до 10 минут; чем больше кодовая база, тем дольше. ▢ Назначен Security Champion. В команде разработки есть человек, умеющий проводить базовый триаж находок и помогать коллегам с разбором алертов. Главное DevSecOps — это процесс, а не набор инструментов. Нельзя просто «купить сканер» и стать защищёнными. Это полноценная работа, которая требует навыков и времени. Главная цель — сделать безопасность естественной частью процесса поставки кода. Предложенные решения не закрывают вопрос безопасности полностью, но помогают выиграть время с минимальными рисками и потерями, пока процесс не перейдёт к профильному специалисту. Шум убивает безопасность. Если CI генерирует сотни ложных срабатываний, разработчики со временем начинают их игнорировать. Поэтому сканер должен сигнализировать только о действительно важных угрозах. Исправлять уязвимости как можно раньше. Чем быстрее проблема обнаружена — например, в IDE или в PR, — тем проще и дешевле её исправить. Поэтому проверки стоит размещать как можно ближе к этапу написания кода. А практики безопасной разработки помогают предотвращать часть уязвимостей ещё до проверок и сокращают объём требующихся исправлений. > Где потренироваться и чему научиться Безопасность в пайплайне перестала быть заботой одного отдела — её всё чаще прикручивают сами разработчики и девопсы. Разобраться стоит заранее, а не когда сканер уже завалил релиз, и начать можно с малого и бесплатного: занятия «Секретный рецепт DevSecOps» — чтобы понять, что на самом деле означает Sec в ежедневной работе DevOps-команды и с чего вообще начинать; открытого вебинара «Информационная безопасность: как построить карьеру в цифровом будущем» — чтобы увидеть, как на практике защищают данные и противостоят атакам, и понять, стоит ли расти в ИБ дальше; мастер-класса «Искусственный интеллект в разработке» — чтобы на реальных примерах посмотреть, как ИИ ускоряет работу разработчика и как это сказывается на трудоустройстве. А если хочется не разовое знакомство, а закрыть то, что в статье осталось за скобками, — DAST, моделирование угроз, защиту контейнеров и требования ФСТЭК, — и вырасти в грейде, стоит смотреть на системное обучение с наставниками и дипломом: на курсе «Специалист по информационной безопасности» — чтобы постепенно войти в ИБ, выбрать специализацию в DevSecOps или Pentest и освоить модули под требования ФСТЭК для работы на крупных проектах; на курсе «DevOps-инженер PRO» — если хочется укрепить сам пайплайн и инфраструктуру: CI/CD, контейнеры и автоматизацию на уровне опытного инженера; на курсе «Нейросети для разработчиков» — чтобы встроить ИИ в повседневную работу, от генерации кода до настройки CI/CD и документации. А чтобы держать знания свежими без привязки к одной программе — инструменты и угрозы в безопасности меняются быстро, — пригодится База знаний Нетологии: 16 000+ видеоуроков и вебинаров по ИТ от практиков из Авито, VK и Яндекса, до 10 роликов в день — бесплатно.

How to find exposed API keys on your website (a 7-step check) Disclosure: we build SniffPup, a free passive scanner for live sites. This guide was first published on our site, and every step works without it. Short answer: anything your site sends to the browser (HTML, JavaScript bundles, source maps, files left in the web root) can be read by every visitor. To find leaked keys, look at your published site the way a stranger would. 1. Know which keys are allowed to be public Some keys are made for the browser: Supabase anon or sb_publishable_ keys, Stripe pk_live_ keys and Firebase web config. Finding them is normal. Secret keys are different. If any of these shows up in your frontend, treat it as leaked: - Supabase service_role or sb_secret_ (they bypass Row Level Security) - Stripe sk_live_ and whsec_ - OpenAI sk- and Anthropic sk-ant- - AWS AKIA… with its secret - GitHub ghp_ - database URLs with a password 2. Search your JavaScript bundles in the browser Open your published site (not the editor preview), open DevTools, then Sources. Press Ctrl+Shift+F (Cmd+Option+F on Mac) to search across all loaded files, and try: sk-, sk-ant-, sk_live_, rk_live_, whsec_ service_role, sb_secret_ AKIA, ghp_, github_pat_, xox, SG., gsk_, xai- PRIVATE KEY, postgres://, mongodb+srv:// Minifying doesn't hide a key: it stays a plain string. Also click around the app with the Network tab open and look at request headers. An Authorization: Bearer sk-… header going from the browser straight to OpenAI or Stripe means the key is in your frontend. 3. Check your build output locally If you have the code, build it and search the output: grep -rnE "sk_live_|sk-|service_role|sb_secret_" dist/ .next/static/ build/ Any environment variable with a VITE_, NEXT_PUBLIC_ or EXPO_PUBLIC_ prefix is copied into the browser bundle by design, so never put a secret in one. 4. Try the files that shouldn't be public Visit these on your live domain: /.env, /.env.local, /.env.production, /.git/config, /.git/HEAD and /.npmrc. - A 404 is good. - Lines like KEY=value or a [core] section mean the file is public. Watch out: many single-page apps return your home page for every unknown URL. That looks like a 200 but is harmless. What matters is whether the real file contents come back. 5. Check for public source maps Open one of your .js files and add .map to the URL. If it downloads, anyone can read your original, unminified source, including comments and any values that were inlined at build time. Turn off production source maps or keep them private. 6. Check your git history too A key you deleted can still live in old commits. Run a tool such as gitleaks or TruffleHog on your repo. An outside scanner (ours included) can't see your repo. 7. If you find a secret key: rotate, then move it server-side 1. Revoke and reissue the key at the provider right away. Deleting it from your code is not enough. 2. Check the provider's usage or billing page for calls you didn't make. 3. Move the call into server-side code (a Supabase Edge Function, an API route or a serverless function) that reads the key from a secret store and checks who is calling. 4. Delete any .env or .git files from the deployed web root and redeploy. 5. Re-check to confirm the leak is gone. If you'd rather automate it A free SniffPup scan of your live URL runs these outside checks: secrets in your HTML and same-origin JS (always masked), public .env/.git files (variable names only, never values), downloadable source maps, security headers and more. It's passive: about 60 requests or fewer, no logins, and it never uses a secret key it finds. It can't see your repo, your server code or anything behind a login, and it doesn't scan native mobile apps. A clean report is not a guarantee of security. FAQ Is it safe to have my Supabase anon key or Stripe publishable key in my frontend? Yes, those keys are designed to be public. But a Supabase anon or sb_publishable_ key is only safe if Row Level Security is on for every exposed table. I deleted the key from my code. Am I safe now? No. If a secret key was ever public, assume someone copied it. Revoke and reissue it at the provider. Removing it from the code only stops new leaks. Does SniffPup use the keys it finds? No. It masks any secret in the report and never uses a secret key it finds. The only key it sends anywhere is the public Supabase anon key your site already ships to every visitor. It uses that for a read-only check (one HEAD request per table, up to 8) that shows whether a signed-out visitor can read at least one row, without downloading any rows. *Feedback shapes what we build next. If there's a check you want, tell us: sniffpup.com

You Deleted the Leaked Key. Git Kept a Copy You deleted the leaked key. Git kept a copy. 6 commands find it. 1 erases it. Deleting a secret in a new commit doesn't remove it from Git. The old commits, the reflog and even a dropped stash still hold it. Every run is real, in a throwaway container against my own demo repo. The AWS key shown is fake (made up, never valid). Rule number one: rotate the key first. Rewriting history doesn't touch clones and forks that already have it. 1. git log -S: pickaxe search, every commit that added or removed a string. git-scm.com 2. git show: the commit that "deleted" the key still prints it in its diff. git-scm.com 3. git blame: the commit, author and time behind each line. git-scm.com 4. git reflog: a reset --hard commit is still in the reflog, and still readable. git-scm.com 5. git fsck --lost-found: a dropped stash becomes a dangling commit you can still read. git-scm.com 6. TruffleHog: scans every commit in the history for secrets. trufflesecurity/trufflehog 7. git filter-repo: the fix. Rotate the key, then rewrite every commit (--replace-text). newren/git-filter-repo GitHub's guide: docs.github.com Where the key should live instead, secrets managers and other DevSecOps tools: stationx.net Free web-book, Become the Cyber Security Expert the AI Era Demands: app.stationx.net Music: "Liberation" by Kraftamt, CC BY 3.0, ccmixter.org #git #devsecops #secrets #appsec #cybersecurity

7 Secret Termux GitHub Hacking Tools For Ethical Hackers 2026 📱 7 Secret Termux GitHub Hacking Tools For Android Hackers 2026 | Ethical Hacking on Android Most people install Termux, run nmap once, and stop there. The people who actually know what Termux is capable of are running tools that crawl web applications with JavaScript rendering, automatically find every URL a domain has ever had from public archives, hunt leaked API keys buried in GitHub commit histories, and run XSS attacks with more intelligence than most desktop scanners. These 7 tools are all on GitHub, all run on Android through Termux, and all used by bug bounty hunters, ethical hackers, and penetration testers in authorized security assessments worldwide. Whether you're studying for OSCP, CEH, building a mobile red team toolkit, or doing authorized bug bounty hunting from your Android phone — these 7 tools level up what Termux can do in 2026. 🔴 ALL 7 TOOLS: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → Smart XSS scanner | Context-aware payload selection | DOM analysis | Blind XSS mode | Go-based, fast | Pipes with GAU for automated XSS discovery ✅ #2 — GAU (github.com/lc/gau) → Get All URLs — Wayback Machine, OTX, URLScan & Common Crawl | Historical URL discovery | Finds deleted endpoints & old admin panels | Pipes into Dalfox & other scanners ✅ #3 — Katana (github.com/projectdiscovery/katana) → Next-gen web crawler | Headless browser JS rendering | Finds hidden endpoints & API calls | Active + passive modes | By ProjectDiscovery | Feeds bug bounty scanners ✅ #4 — Photon (github.com/s0md3v/Photon) → OSINT web crawler | Extracts emails, links, API keys in JS files, subdomains & comments | Authorized recon intelligence gathering | Fast & lightweight ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → All-in-one web recon & vulnerability scanner | IP, WHOIS, subdomains, ports, CMS detection, SQLi, XSS & header analysis | WordPress & Joomla vuln checks | Single menu interface ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → Scans GitHub repos & commit history for leaked secrets | API keys, tokens, AWS credentials, passwords | Finds secrets deleted in later commits | Bug bounty goldmine ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → Most advanced XSS detection suite on GitHub | Context-specific payload generation | WAF detection & bypass | DOM XSS scanner | Fuzzer & crawler included 🔗 ALL GITHUB LINKS: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 Sponsorships & Business: sponsors.hackerslegacy.com 📚 Cybersecurity Blogs: hackerslegacy.com 📄 Support Us — PDF Guides: store.hackerslegacy.com ⚠️ DISCLAIMER: All tools are for authorized bug bounty programs, ethical security research, and penetration testing with explicit written permission only. Unauthorized use is illegal. Ethical use always. 📌 Which of these 7 is going on your phone first? Drop it in the comments! 🔔 Subscribe for weekly Termux tools, Android hacking, and ethical hacking content. Not sponsored. All tools free and open source. Authorized use only. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [ar] 7 أدوات سرية على Termux من GitHub لاختراق الأخلاقي لعام 2026 📱 ٧ أدوات اختراق سرية لـ Termux وGitHub لمخترقي أندرويد ٢٠٢٦ | الاختراق الأخلاقي على أندرويد يكتفي معظم المستخدمين بتثبيت Termux وتشغيل nmap مرة واحدة. أما من يعرفون حقًا إمكانيات Termux، فيستخدمون أدواتٍ قادرة على فهرسة تطبيقات الويب باستخدام JavaScript، والعثور تلقائيًا على جميع عناوين URL التي استخدمها أي نطاق من الأرشيفات العامة، والبحث عن مفاتيح API المسربة المخفية في سجلات GitHub، وتنفيذ هجمات XSS بذكاء يفوق معظم برامج فحص سطح المكتب. هذه الأدوات السبع متوفرة جميعها على GitHub، وتعمل جميعها على أندرويد من خلال Termux، ويستخدمها باحثو الثغرات الأمنية، والمخترقون الأخلاقيون، ومختبرو الاختراق في تقييمات أمنية معتمدة حول العالم. هذه الأدوات السبع موجودة جميعها على GitHub، وتعمل جميعها على أندرويد من خلال Termux، ويستخدمها باحثو الثغرات الأمنية، والمخترقون الأخلاقيون، ومختبرو الاختراق في تقييمات أمنية معتمدة عالميًا. سواء كنت تستعد لاختبارات OSCP أو CEH، أو تُنشئ مجموعة أدوات فريق الهجوم الإلكتروني للأجهزة المحمولة، أو تُجري عمليات بحث عن الثغرات الأمنية المُصرّح بها من هاتفك الأندرويد، فإن هذه الأدوات السبع تُعزز إمكانيات Termux في عام 2026. 🔴 جميع الأدوات السبع: ✅ #1 — Dalfox (github.com/hahwul/dalfox) ← ماسح ذكي لهجمات XSS | اختيار الحمولة بناءً على السياق | تحليل DOM | وضع XSS الأعمى | سريع ومبني على لغة Go | يتكامل مع GAU لاكتشاف هجمات XSS تلقائيًا ✅ #2 — GAU (github.com/lc/gau) ← الحصول على جميع عناوين URL — Wayback Machine وOTX وURLScan وCommon Crawl | اكتشاف عناوين URL التاريخية | العثور على نقاط النهاية المحذوفة ولوحات التحكم القديمة | يتكامل مع Dalfox وماسحات أخرى ✅ #3 — Katana (github.com/projectdiscovery/katana) ← جيل جديد من برامج زحف الويب | عرض جافا سكريبت في المتصفح بدون واجهة رسومية | يكشف عن نقاط النهاية المخفية واستدعاءات واجهة برمجة التطبيقات | وضعان: نشط وسلبي | من تطوير ProjectDiscovery | يغذي ماسحات مكافآت الثغرات ✅ #4 — Photon (github.com/s0md3v/Photon) ← زاحف ويب مفتوح المصدر | يستخرج رسائل البريد الإلكتروني والروابط ومفاتيح واجهة برمجة التطبيقات من ملفات جافا سكريبت والنطاقات الفرعية والتعليقات | جمع معلومات استخباراتية مُصرّح به | سريع وخفيف الوزن ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) ← ماسح شامل لاستطلاع الويب والثغرات الأمنية | كشف عناوين IP وWHOIS والنطاقات الفرعية والمنافذ وأنظمة إدارة المحتوى وثغرات SQLi وXSS وتحليل الترويسات | فحص ثغرات WordPress وJoomla | واجهة قائمة واحدة ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) ← يفحص مستودعات GitHub وسجل التغييرات بحثًا عن أسرار مُسرّبة | مفاتيح واجهة برمجة التطبيقات والرموز المميزة وبيانات اعتماد AWS وكلمات المرور | يكشف عن الأسرار المحذوفة في التحديثات اللاحقة | كنزٌ ثمينٌ من مكافآت اكتشاف الثغرات ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → أقوى مجموعة أدوات لكشف هجمات XSS على GitHub | توليد حمولات مُخصصة للسياق | كشف وتجاوز جدار حماية تطبيقات الويب | ماسح ضوئي لهجمات XSS في DOM | يتضمن البرنامج أدوات فحص واختبار الزحف 🔗 جميع روابط GitHub: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 الرعاية والتواصل التجاري: sponsors.hackerslegacy.com 📚 مدونات الأمن السيبراني: hackerslegacy.com 📄 ادعمنا - أدلة PDF: store.hackerslegacy.com ⚠️ تنويه: جميع الأدوات مخصصة لبرامج مكافآت اكتشاف الثغرات الأمنية المعتمدة، وأبحاث الأمن الأخلاقي، واختبارات الاختراق، وذلك بإذن كتابي صريح فقط. الاستخدام غير المصرح به غير قانوني. الاستخدام الأخلاقي هو الأساس. 📌 أي من هذه الأدوات السبع ستثبتها على هاتفك أولاً؟ شاركنا رأيك في التعليقات! 🔔 اشترك للحصول على محتوى أسبوعي حول أدوات Termux، واختراق أجهزة أندرويد، والاختراق الأخلاقي. غير مدعوم. جميع الأدوات مجانية ومفتوحة المصدر. الاستخدام المصرح به فقط. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [bn] এথিক্যাল হ্যাকারদের জন্য ৭টি গোপন Termux গিটহাব হ্যাকিং টুলস ২০২৬ 📱 অ্যান্ড্রয়েড হ্যাকারদের জন্য ২০২৬ সালের ৭টি গোপন টার্মাক্স গিটহাব হ্যাকিং টুল | অ্যান্ড্রয়েডে এথিক্যাল হ্যাকিং বেশিরভাগ মানুষ টার্মাক্স ইনস্টল করে, একবার এনম্যাপ (nmap) চালায় এবং সেখানেই থেমে যায়। যারা আসলেই জানেন টার্মাক্স কী করতে সক্ষম, তারা এমন সব টুল ব্যবহার করেন যা জাভাস্ক্রিপ্ট রেন্ডারিং সহ ওয়েব অ্যাপ্লিকেশন ক্রল করে, পাবলিক আর্কাইভ থেকে একটি ডোমেইনের অতীতের সমস্ত ইউআরএল (URL) স্বয়ংক্রিয়ভাবে খুঁজে বের করে, গিটহাব কমিট হিস্টোরিতে চাপা পড়া ফাঁস হওয়া এপিআই কী (API key) অনুসন্ধান করে এবং বেশিরভাগ ডেস্কটপ স্ক্যানারের চেয়েও বেশি বুদ্ধিমত্তার সাথে এক্সএসএস (XSS) অ্যাটাক চালায়। এই ৭টি টুলই গিটহাবে রয়েছে, সবগুলোই টার্মাক্সের মাধ্যমে অ্যান্ড্রয়েডে চলে এবং বিশ্বজুড়ে অনুমোদিত নিরাপত্তা মূল্যায়নে বাগ বাউন্টি হান্টার, এথিক্যাল হ্যাকার এবং পেনিট্রেশন টেস্টাররা এগুলো ব্যবহার করেন। আপনি OSCP বা CEH-এর জন্য পড়াশোনা করুন, একটি মোবাইল রেড টিম টুলকিট তৈরি করুন, অথবা আপনার অ্যান্ড্রয়েড ফোন থেকে অনুমোদিত বাগ বাউন্টি হান্টিং করুন — এই ৭টি টুল ২০২৬ সালে Termux-এর সক্ষমতাকে এক নতুন স্তরে উন্নীত করবে। 🔴 সব ৭টি টুল: ✅ #১ — Dalfox (github.com/hahwul/dalfox) → স্মার্ট XSS স্ক্যানার | কনটেক্সট-অ্যাওয়্যার পেলোড সিলেকশন | DOM অ্যানালাইসিস | ব্লাইন্ড XSS মোড | Go-ভিত্তিক, দ্রুত | স্বয়ংক্রিয় XSS আবিষ্কারের জন্য GAU-এর সাথে পাইপিং ✅ #২ — GAU (github.com/lc/gau) → সমস্ত URL খুঁজে বের করে — Wayback Machine, OTX, URLScan এবং Common Crawl | ঐতিহাসিক URL আবিষ্কার | মুছে ফেলা এন্ডপয়েন্ট এবং পুরানো অ্যাডমিন প্যানেল খুঁজে বের করে | Dalfox এবং অন্যান্য স্ক্যানারের সাথে পাইপিং ✅ #৩ — Katana (github.com/projectdiscovery/katana) → নেক্সট-জেন ওয়েব ক্রলার | হেডলেস ব্রাউজার JS রেন্ডারিং | লুকানো এন্ডপয়েন্ট এবং এপিআই কল খুঁজে বের করে | অ্যাক্টিভ + প্যাসিভ মোড | প্রজেক্টডিসকভারি দ্বারা নির্মিত | বাগ বাউন্টি স্ক্যানারকে ডেটা সরবরাহ করে ✅ #৪ — ফোটন (github.com/s0md3v/Photon) → OSINT ওয়েব ক্রলার | JS ফাইল, সাবডোমেইন এবং কমেন্ট থেকে ইমেল, লিঙ্ক, এপিআই কী বের করে | অনুমোদিত রিকন ইন্টেলিজেন্স সংগ্রহ | দ্রুত এবং হালকা ✅ #৫ — রেড হক (github.com/Tuhinshubhra/RED_HAWK) → অল-ইন-ওয়ান ওয়েব রিকন এবং ভালনারেবিলিটি স্ক্যানার | আইপি, হু-ইজ, সাবডোমেইন, পোর্ট, সিএমএস ডিটেকশন, SQLi, XSS এবং হেডার বিশ্লেষণ | ওয়ার্ডপ্রেস এবং জুমলা ভালনারেবিলিটি চেক | সিঙ্গেল মেনু ইন্টারফেস ✅ #৬ — ট্রাফলহগ (github.com/trufflesecurity/trufflehog) → ফাঁস হওয়া সিক্রেটের জন্য গিটহাব রিপো এবং কমিট হিস্ট্রি স্ক্যান করে | এপিআই কী, টোকেন, AWS ক্রেডেনশিয়াল, পাসওয়ার্ড | পরবর্তী কমিটে মুছে ফেলা সিক্রেট খুঁজে বের করে | বাগ বাউন্টির সোনার খনি ✅ #৭ — XSStrike (github.com/s0md3v/XSStrike) → গিটহাবের সবচেয়ে উন্নত XSS সনাক্তকরণ স্যুট | প্রেক্ষাপট-নির্দিষ্ট পেলোড তৈরি | WAF সনাক্তকরণ ও বাইপাস | DOM XSS স্ক্যানার | ফাজার ও ক্রলার অন্তর্ভুক্ত 🔗 সমস্ত গিটহাব লিঙ্ক: → ডালফক্স: hahwul/dalfox → জিএইউ: lc/gau → কাটানা: projectdiscovery/katana → ফোটন: s0md3v/Photon → রেড হক: Tuhinshubhra/RED_HAWK → ট্রাফলহগ: trufflesecurity/trufflehog → এক্সএসস্ট্রাইক: s0md3v/XSStrike 💼 পৃষ্ঠপোষকতা ও ব্যবসায়িক যোগাযোগ: sponsors.hackerslegacy.com 📚 সাইবারসিকিউরিটি ব্লগ: hackerslegacy.com 📄 আমাদের সমর্থন করুন — পিডিএফ গাইড: store.hackerslegacy.com ⚠️ সতর্কীকরণ: সমস্ত টুল শুধুমাত্র সুস্পষ্ট লিখিত অনুমতি সাপেক্ষে অনুমোদিত বাগ বাউন্টি প্রোগ্রাম, নৈতিক নিরাপত্তা গবেষণা এবং পেনিট্রেশন টেস্টিং-এর জন্য ব্যবহার্য। অনুমতি ছাড়া ব্যবহার অবৈধ। সর্বদা নৈতিক ব্যবহার আবশ্যক। 📌 এই ৭টির মধ্যে কোনটি আপনি প্রথমে আপনার ফোনে ব্যবহার করবেন? কমেন্টে জানান! 🔔 সাপ্তাহিক Termux টুল, অ্যান্ড্রয়েড হ্যাকিং এবং এথিক্যাল হ্যাকিং কন্টেন্টের জন্য সাবস্ক্রাইব করুন। কোনো স্পনসরড পোস্ট নয়। সমস্ত টুল বিনামূল্যে এবং ওপেন সোর্স। শুধুমাত্র অনুমোদিত ব্যবহার। #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [de-DE] 7 geheime Termux GitHub-Hacking-Tools für Ethical Hacker 2026 📱 7 geheime Termux-GitHub-Hacking-Tools für Android-Hacker 2026 | Ethisches Hacking auf Android Die meisten installieren Termux, führen einmal nmap aus und belassen es dabei. Diejenigen, die das volle Potenzial von Termux ausschöpfen, nutzen Tools, die Webanwendungen mit JavaScript-Rendering durchsuchen, automatisch alle URLs einer Domain aus öffentlichen Archiven finden, in GitHub-Commit-Verläufen versteckte API-Schlüssel aufspüren und XSS-Angriffe mit mehr Intelligenz als die meisten Desktop-Scanner durchführen. Diese 7 Tools sind alle auf GitHub verfügbar, laufen alle unter Android über Termux und werden von Bug-Bounty-Jägern, ethischen Hackern und Penetrationstestern weltweit in autorisierten Sicherheitsprüfungen eingesetzt. Egal, ob du für OSCP oder CEH lernst, ein mobiles Red-Team-Toolkit entwickelst oder autorisierte Bug-Bounty-Jagd mit deinem Android-Smartphone betreibst – diese 7 Tools erweitern die Möglichkeiten von Termux bis 2026. 🔴 ALLE 7 TOOLS: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → Intelligenter XSS-Scanner | Kontextabhängige Payload-Auswahl | DOM-Analyse | Blind-XSS-Modus | Go-basiert, schnell | Integration mit GAU für die automatisierte XSS-Erkennung ✅ #2 — GAU (github.com/lc/gau) → Alle URLs abrufen – Wayback Machine, OTX, URLScan & Common Crawl | Historische URL-Erkennung | Findet gelöschte Endpunkte und alte Admin-Panels | Integration mit Dalfox und anderen Scannern ✅ #3 — Katana (github.com/projectdiscovery/katana) → Webcrawler der nächsten Generation | Headless-Browser-JS-Rendering | Findet versteckte Endpunkte und API-Aufrufe | Aktiver und passiver Modus | Von ProjectDiscovery | Liefert Daten an Bug-Bounty-Scanner ✅ #4 — Photon (github.com/s0md3v/Photon) → OSINT-Webcrawler | Extrahiert E-Mails, Links und API-Schlüssel aus JS-Dateien, Subdomains und Kommentaren | Autorisierte Informationsbeschaffung | Schnell und ressourcenschonend ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → All-in-One-Web-Reconnaissance- und Schwachstellenscanner | IP-, WHOIS-, Subdomain-, Port- und CMS-Erkennung, SQLi-, XSS- und Header-Analyse | WordPress- und Joomla-Schwachstellenprüfung | Benutzeroberfläche mit einfacher Menüführung ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → Durchsucht GitHub-Repos und Commit-Historie nach geleakten Geheimnissen | API-Schlüssel, Tokens, AWS-Zugangsdaten, Passwörter | Findet in späteren Commits gelöschte Geheimnisse | Bug-Bounty-Goldgrube ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → Die fortschrittlichste XSS-Erkennungssuite auf GitHub | Kontextspezifische Payload-Generierung | WAF-Erkennung & -Umgehung | DOM-XSS-Scanner | Fuzzer & Crawler enthalten 🔗 ALLE GITHUB-LINKS: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 Sponsoring & Geschäftliches: sponsors.hackerslegacy.com 📚 Cybersecurity-Blogs: hackerslegacy.com 📄 Unterstütze uns – PDF-Anleitungen: store.hackerslegacy.com ⚠️ HINWEIS: Alle Tools sind ausschließlich für autorisierte Bug-Bounty-Programme, ethische Sicherheitsforschung und Penetrationstests mit ausdrücklicher schriftlicher Genehmigung bestimmt. Unautorisierte Nutzung ist illegal. Ethische Nutzung ist immer geboten. 📌 Welches dieser 7 Tools kommt als erstes auf dein Handy? Schreib es in die Kommentare! 🔔 Abonniere unseren Kanal für wöchentliche Inhalte zu Termux-Tools, Android-Hacking und ethischem Hacking. Nicht gesponsert. Alle Tools sind kostenlos und Open Source. Nur autorisierte Nutzung. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [es-US] 7 herramientas de hacking secretas de GitHub para Termux para hackers éticos 2026 📱 7 Herramientas Secretas de Hacking en GitHub con Termux para Hackers de Android (2026) | Hacking Ético en Android La mayoría instala Termux, ejecuta nmap una vez y ahí se queda. Quienes realmente conocen el potencial de Termux utilizan herramientas que rastrean aplicaciones web con renderizado JavaScript, encuentran automáticamente todas las URL de un dominio en archivos públicos, buscan claves API filtradas ocultas en el historial de commits de GitHub y realizan ataques XSS con mayor inteligencia que la mayoría de los escáneres de escritorio. Estas 7 herramientas están en GitHub, se ejecutan en Android a través de Termux y son utilizadas por cazadores de recompensas por errores, hackers éticos y pentesters en evaluaciones de seguridad autorizadas en todo el mundo. Ya sea que estés estudiando para OSCP, CEH, creando un kit de herramientas para equipos rojos móviles o realizando búsquedas de recompensas por errores autorizadas desde tu teléfono Android, estas 7 herramientas llevan Termux a otro nivel en 2026. 🔴 LAS 7 HERRAMIENTAS: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → Escáner XSS inteligente | Selección de payloads con reconocimiento de contexto | Análisis DOM | Modo XSS ciego | Basado en Go, rápido | Se integra con GAU para la detección automatizada de XSS ✅ #2 — GAU (github.com/lc/gau) → Obtiene todas las URL: Wayback Machine, OTX, URLScan y Common Crawl | Descubrimiento de URL históricas | Encuentra endpoints eliminados y paneles de administración antiguos | Se integra con Dalfox y otros escáneres ✅ #3 — Katana (github.com/projectdiscovery/katana) → Rastreador web de última generación | Renderizado de JavaScript en navegador sin interfaz gráfica | Encuentra endpoints y llamadas a API ocultas | Modos activo y pasivo | Desarrollado por ProjectDiscovery | Alimenta escáneres de recompensas por detección de errores ✅ #4 — Photon (github.com/s0md3v/Photon) → Rastreador web OSINT | Extrae correos electrónicos, enlaces, claves API en archivos JS, subdominios y comentarios | Recopilación de inteligencia de reconocimiento autorizada | Rápido y ligero ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → Escáner de reconocimiento web y vulnerabilidades todo en uno | IP, WHOIS, subdominios, puertos, detección de CMS, SQLi, XSS y análisis de encabezados | Verificación de vulnerabilidades en WordPress y Joomla | Interfaz de menú único ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → Escanea repositorios de GitHub e historial de confirmaciones en busca de secretos filtrados | Claves API, tokens, credenciales de AWS, contraseñas | Encuentra secretos eliminados en confirmaciones posteriores | Mina de oro de recompensas por errores ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → El conjunto de herramientas de detección de XSS más avanzado en GitHub | Generación de payloads específicos del contexto | Detección y evasión de WAF | Escáner XSS del DOM | Fuzzer y rastreador incluidos 🔗 TODOS LOS ENLACES DE GITHUB: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 Patrocinios y negocios: sponsors.hackerslegacy.com 📚 Blogs de ciberseguridad: hackerslegacy.com 📄 Apóyanos: Guías en PDF: store.hackerslegacy.com ⚠️ AVISO: Todas las herramientas son solo para programas autorizados de recompensas por detección de errores, investigación ética de seguridad y pruebas de penetración con autorización explícita por escrito. El uso no autorizado es ilegal. Uso ético siempre. 📌 ¿Cuál de estas 7 herramientas instalarás primero en tu teléfono? ¡Cuéntanos en los comentarios! 🔔 Suscríbete para recibir contenido semanal sobre herramientas de Termux, hacking de Android y hacking ético. Sin patrocinio. Todas las herramientas son gratuitas y de código abierto. Solo para uso autorizado. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [fr-FR] 7 outils de piratage GitHub secrets sur Termux pour les hackers éthiques en 2026 📱 7 outils secrets Termux pour le piratage GitHub sur Android (2026) | Piratage éthique sur Android La plupart des utilisateurs installent Termux, lancent nmap une seule fois et s'arrêtent là. Ceux qui maîtrisent réellement les capacités de Termux utilisent des outils capables d'explorer les applications web avec rendu JavaScript, de retrouver automatiquement toutes les URL d'un domaine dans les archives publiques, de dénicher les clés API divulguées enfouies dans l'historique des commits GitHub et de mener des attaques XSS avec une intelligence supérieure à celle de la plupart des scanners de bureau. Ces 7 outils sont tous disponibles sur GitHub, fonctionnent sur Android via Termux et sont utilisés par les chasseurs de bugs, les hackers éthiques et les testeurs d'intrusion lors d'audits de sécurité autorisés à travers le monde. Que vous prépariez les certifications OSCP et CEH, développiez une boîte à outils de test d'intrusion mobile ou pratiquiez la chasse aux bugs autorisée depuis votre téléphone Android, ces 7 outils optimisent les capacités de Termux en 2026. 🔴 LES 7 OUTILS : ✅ N° 1 — Dalfox (github.com/hahwul/dalfox) → Scanner XSS intelligent | Sélection de la charge utile contextuelle | Analyse DOM | Mode XSS aveugle | Basé sur Go, rapide | Intégration avec GAU pour la découverte automatisée de XSS ✅ N° 2 — GAU (github.com/lc/gau) → Récupération de toutes les URL — Wayback Machine, OTX, URLScan et Common Crawl | Découverte d'URL historiques | Détection des points de terminaison supprimés et des anciens panneaux d'administration | Intégration avec Dalfox et d'autres scanners ✅ N° 3 — Katana (github.com/projectdiscovery/katana) → Robot d'exploration web nouvelle génération | Rendu JS sans interface graphique | Détecte les points de terminaison et les appels API cachés | Modes actif et passif | Par ProjectDiscovery | Alimente les scanners de primes aux bogues ✅ #4 — Photon (github.com/s0md3v/Photon) → Robot d'exploration web OSINT | Extrait les e-mails, les liens et les clés API dans les fichiers JS, les sous-domaines et les commentaires | Collecte de renseignements autorisée | Rapide et léger ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → Scanner de vulnérabilités et de reconnaissance web tout-en-un | Détection d'IP, WHOIS, de sous-domaines, de ports, de CMS, d'injections SQL, de XSS et d'en-têtes | Vérification des vulnérabilités WordPress et Joomla | Interface à menu unique ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → Analyse les dépôts GitHub et l'historique des commits à la recherche de secrets divulgués | Clés API, jetons, identifiants AWS, mots de passe | Détecte les secrets supprimés dans les commits ultérieurs | La mine d'or des programmes de primes aux bogues ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → La suite de détection XSS la plus avancée sur GitHub | Génération de payloads contextuels | Détection et contournement des WAF | Scanner XSS DOM | Fuzzer et crawler inclus 🔗 TOUS LES LIENS GITHUB : → Dalfox : hahwul/dalfox → GAU : lc/gau → Katana : projectdiscovery/katana → Photon : s0md3v/Photon → Red Hawk : Tuhinshubhra/RED_HAWK → TruffleHog : trufflesecurity/trufflehog → XSStrike : s0md3v/XSStrike 💼 Partenariats et partenariats : sponsors.hackerslegacy.com 📚 Blogs sur la cybersécurité : hackerslegacy.com 📄 Soutenez-nous — Guides PDF : store.hackerslegacy.com ⚠️ AVERTISSEMENT : Tous les outils sont destinés exclusivement aux programmes de chasse aux bugs autorisés, à la recherche en sécurité éthique et aux tests d'intrusion, avec autorisation écrite explicite. Toute utilisation non autorisée est illégale. Privilégiez toujours une utilisation éthique. 📌 Lequel de ces 7 outils installerez-vous en premier sur votre téléphone ? Dites-le-nous en commentaire ! 🔔 Abonnez-vous pour recevoir chaque semaine des contenus sur les outils Termux, le hacking Android et le hacking éthique. Non sponsorisé. Tous les outils sont gratuits et open source. Utilisation autorisée uniquement. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [hi] एथिकल हैकर्स के लिए 7 गुप्त Termux GitHub हैकिंग टूल्स 2026 📱 एंड्रॉइड हैकर्स के लिए 7 गुप्त टर्मक्स गिटहब हैकिंग टूल्स 2026 | एंड्रॉइड पर एथिकल हैकिंग अधिकांश लोग टर्मक्स इंस्टॉल करते हैं, एक बार nmap चलाते हैं और वहीं रुक जाते हैं। जो लोग वास्तव में टर्मक्स की क्षमताओं को जानते हैं, वे ऐसे टूल्स का उपयोग कर रहे हैं जो जावास्क्रिप्ट रेंडरिंग वाले वेब एप्लिकेशन को क्रॉल करते हैं, सार्वजनिक आर्काइव से किसी डोमेन के सभी यूआरएल को स्वचालित रूप से खोजते हैं, गिटहब कमिट हिस्ट्री में छिपी हुई लीक हुई एपीआई कुंजी का पता लगाते हैं, और अधिकांश डेस्कटॉप स्कैनर्स की तुलना में अधिक बुद्धिमत्ता के साथ XSS हमले करते हैं। ये 7 टूल्स सभी गिटहब पर उपलब्ध हैं, सभी टर्मक्स के माध्यम से एंड्रॉइड पर चलते हैं, और दुनिया भर में अधिकृत सुरक्षा मूल्यांकन में बग बाउंटी हंटर्स, एथिकल हैकर्स और पेनिट्रेशन टेस्टर्स द्वारा उपयोग किए जाते हैं। चाहे आप OSCP या CEH की तैयारी कर रहे हों, मोबाइल रेड टीम टूलकिट बना रहे हों, या अपने Android फ़ोन से अधिकृत बग बाउंटी हंटिंग कर रहे हों — ये 7 टूल Termux की क्षमताओं को 2026 में और भी उन्नत बना देंगे। 🔴 सभी 7 टूल: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → स्मार्ट XSS स्कैनर | संदर्भ-आधारित पेलोड चयन | DOM विश्लेषण | ब्लाइंड XSS मोड | Go-आधारित, तेज़ | स्वचालित XSS खोज के लिए GAU के साथ पाइपिंग ✅ #2 — GAU (github.com/lc/gau) → सभी URL प्राप्त करें — Wayback Machine, OTX, URLScan और Common Crawl | ऐतिहासिक URL खोज | हटाए गए एंडपॉइंट और पुराने एडमिन पैनल खोजता है | Dalfox और अन्य स्कैनर्स में पाइपिंग ✅ #3 — Katana (github.com/projectdiscovery/katana) → अगली पीढ़ी का वेब क्रॉलर | हेडलेस ब्राउज़र JS रेंडरिंग | छिपे हुए एंडपॉइंट्स और API कॉल्स का पता लगाता है | सक्रिय + निष्क्रिय मोड | प्रोजेक्टडिस्कवरी द्वारा | बग बाउंटी स्कैनर्स को फ़ीड करता है ✅ #4 — फोटॉन (github.com/s0md3v/Photon) → OSINT वेब क्रॉलर | JS फ़ाइलों, सबडोमेन और टिप्पणियों में ईमेल, लिंक, API कुंजी निकालता है | अधिकृत रिकॉन इंटेलिजेंस संग्रह | तेज़ और हल्का ✅ #5 — रेड हॉक (github.com/Tuhinshubhra/RED_HAWK) → ऑल-इन-वन वेब रिकॉन और वल्नरेबिलिटी स्कैनर | IP, WHOIS, सबडोमेन, पोर्ट, CMS डिटेक्शन, SQLi, XSS और हेडर विश्लेषण | वर्डप्रेस और जूमला वल्नरेबिलिटी जांच | सिंगल मेनू इंटरफ़ेस ✅ #6 — ट्रफलहॉग (github.com/trufflesecurity/trufflehog) → लीक हुए सीक्रेट्स के लिए GitHub रिपॉजिटरी और कमिट हिस्ट्री को स्कैन करता है | API कुंजी, टोकन, AWS क्रेडेंशियल, पासवर्ड | बाद के कमिट में हटाए गए गुप्त कोड ढूंढता है | बग बाउंटी का खजाना ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → GitHub पर सबसे उन्नत XSS डिटेक्शन सूट | संदर्भ-विशिष्ट पेलोड जनरेशन | WAF डिटेक्शन और बाईपास | DOM XSS स्कैनर | फ़ज़र और क्रॉलर शामिल हैं 🔗 सभी GitHub लिंक: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 प्रायोजन और व्यवसाय: sponsors.hackerslegacy.com 📚 साइबर सुरक्षा ब्लॉग: hackerslegacy.com 📄 हमारा समर्थन करें — PDF गाइड: store.hackerslegacy.com ⚠️ अस्वीकरण: सभी उपकरण केवल अधिकृत बग बाउंटी प्रोग्राम, नैतिक सुरक्षा अनुसंधान और स्पष्ट लिखित अनुमति के साथ पेनिट्रेशन टेस्टिंग के लिए हैं। अनाधिकृत उपयोग अवैध है। हमेशा नैतिक उपयोग करें। 📌 इन 7 में से कौन सा टूल आप सबसे पहले अपने फोन में इंस्टॉल करेंगे? कमेंट में बताएं! 🔔 टर्मक्स टूल्स, एंड्रॉइड हैकिंग और नैतिक हैकिंग से संबंधित साप्ताहिक सामग्री के लिए सब्सक्राइब करें। प्रायोजित नहीं। सभी उपकरण निःशुल्क और ओपन सोर्स हैं। केवल अधिकृत उपयोग। #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [id] 7 Tools Hacking GitHub Termux Rahasia Untuk Ethical Hacker 2026 📱 7 Alat Rahasia Termux untuk Hacking GitHub bagi Peretas Android 2026 | Peretasan Etis di Android Sebagian besar orang menginstal Termux, menjalankan nmap sekali, dan berhenti di situ. Orang-orang yang benar-benar tahu kemampuan Termux menjalankan alat-alat yang merayapi aplikasi web dengan rendering JavaScript, secara otomatis menemukan setiap URL yang pernah dimiliki suatu domain dari arsip publik, memburu kunci API yang bocor yang terkubur dalam riwayat commit GitHub, dan menjalankan serangan XSS dengan kecerdasan lebih tinggi daripada kebanyakan pemindai desktop. Ketujuh alat ini semuanya ada di GitHub, semuanya berjalan di Android melalui Termux, dan semuanya digunakan oleh pemburu bug bounty, peretas etis, dan penguji penetrasi dalam penilaian keamanan resmi di seluruh dunia. Baik Anda sedang belajar untuk OSCP, CEH, membangun perangkat tim merah seluler, atau melakukan perburuan bug bounty resmi dari ponsel Android Anda — 7 alat ini meningkatkan kemampuan Termux di tahun 2026. 🔴 SEMUA 7 ALAT: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → Pemindai XSS cerdas | Pemilihan payload yang peka konteks | Analisis DOM | Mode XSS buta | Berbasis Go, cepat | Pipes dengan GAU untuk penemuan XSS otomatis ✅ #2 — GAU (github.com/lc/gau) → Dapatkan Semua URL — Wayback Machine, OTX, URLScan & Common Crawl | Penemuan URL historis | Menemukan endpoint yang dihapus & panel admin lama | Terhubung ke Dalfox & pemindai lainnya ✅ #3 — Katana (github.com/projectdiscovery/katana) → Perayap web generasi berikutnya | Rendering JS browser tanpa antarmuka grafis | Menemukan titik akhir tersembunyi & panggilan API | Mode aktif + pasif | Oleh ProjectDiscovery | Memberi umpan ke pemindai bug bounty ✅ #4 — Photon (github.com/s0md3v/Photon) → Perayap web OSINT | Mengekstrak email, tautan, kunci API dalam file JS, subdomain & komentar | Pengumpulan intelijen pengintaian resmi | Cepat & ringan ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → Pemindai pengintaian web & kerentanan all-in-one | Deteksi IP, WHOIS, subdomain, port, CMS, SQLi, XSS & analisis header | Pemeriksaan kerentanan WordPress & Joomla | Antarmuka menu tunggal ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → Memindai repositori GitHub & riwayat commit untuk rahasia yang bocor | Kunci API, token, kredensial AWS, kata sandi | Menemukan rahasia yang dihapus dalam commit selanjutnya | Tambang emas bug bounty ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → Rangkaian deteksi XSS paling canggih di GitHub | Pembuatan payload spesifik konteks | Deteksi & bypass WAF | Pemindai XSS DOM | Fuzzer & crawler disertakan 🔗 SEMUA LINK GITHUB: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 Sponsor & Bisnis: sponsors.hackerslegacy.com 📚 Blog Keamanan Siber: hackerslegacy.com 📄 Dukung Kami — Panduan PDF: store.hackerslegacy.com ⚠️ PENAFIAN: Semua alat hanya untuk program bug bounty resmi, riset keamanan etis, dan pengujian penetrasi dengan izin tertulis yang jelas. Penggunaan tanpa izin adalah ilegal. Selalu gunakan secara etis. 📌 Manakah dari 7 alat ini yang akan Anda pasang di ponsel Anda terlebih dahulu? Tulis di kolom komentar! 🔔 Berlangganan untuk mendapatkan konten mingguan tentang alat Termux, peretasan Android, dan peretasan etis. Tidak disponsori. Semua alat gratis dan open source. Hanya untuk penggunaan resmi. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [it] 7 Strumenti di hacking segreti su GitHub per Termux per Ethical Hacker 2026 📱 7 Strumenti segreti di Termux per l'hacking di GitHub per hacker Android 2026 | Hacking etico su Android Molti installano Termux, eseguono nmap una volta e si fermano lì. Chi invece conosce davvero le potenzialità di Termux utilizza strumenti in grado di analizzare applicazioni web con rendering JavaScript, trovare automaticamente ogni URL mai posseduto da un dominio negli archivi pubblici, scovare chiavi API trapelate nascoste nella cronologia dei commit di GitHub ed eseguire attacchi XSS con un livello di intelligenza superiore a quello della maggior parte degli scanner per desktop. Questi 7 strumenti sono tutti disponibili su GitHub, funzionano tutti su Android tramite Termux e sono utilizzati da bug bounty hunter, hacker etici e penetration tester in valutazioni di sicurezza autorizzate in tutto il mondo. Che tu stia studiando per la certificazione OSCP o CEH, creando un toolkit per red team mobile o partecipando a programmi di bug bounty autorizzati dal tuo telefono Android, questi 7 strumenti portano Termux a un livello superiore nel 2026. 🔴 TUTTI E 7 GLI STRUMENTI: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → Scanner XSS intelligente | Selezione del payload contestuale | Analisi del DOM | Modalità XSS cieca | Basato su Go, veloce | Integrato con GAU per il rilevamento automatico di XSS ✅ #2 — GAU (github.com/lc/gau) → Ottieni tutti gli URL — Wayback Machine, OTX, URLScan e Common Crawl | Rilevamento URL storici | Trova endpoint eliminati e vecchi pannelli di amministrazione | Integrato con Dalfox e altri scanner ✅ #3 — Katana (github.com/projectdiscovery/katana) → Web crawler di nuova generazione | Rendering JS in browser headless | Trova endpoint nascosti e chiamate API | Modalità attiva e passiva | Sviluppato da ProjectDiscovery | Alimenta gli scanner di bug bounty ✅ #4 — Photon (github.com/s0md3v/Photon) → Web crawler OSINT | Estrae email, link e chiavi API da file JS, sottodomini e commenti | Raccolta di informazioni di ricognizione autorizzata | Veloce e leggero ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → Scanner web completo per ricognizione e vulnerabilità | Rilevamento di IP, WHOIS, sottodomini, porte, CMS, SQLi, XSS e analisi delle intestazioni | Verifica delle vulnerabilità di WordPress e Joomla | Interfaccia a menu singolo ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → Scansiona repository GitHub e cronologia dei commit alla ricerca di segreti trapelati | Chiavi API, token, credenziali AWS, password | Trova segreti cancellati nei commit successivi | Miniera d'oro per il bug bounty ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → La suite di rilevamento XSS più avanzata su GitHub | Generazione di payload specifici per il contesto | Rilevamento e bypass del WAF | Scanner XSS DOM | Fuzzer e crawler inclusi 🔗 TUTTI I LINK GITHUB: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 Sponsorizzazioni e collaborazioni commerciali: sponsors.hackerslegacy.com 📚 Blog sulla sicurezza informatica: hackerslegacy.com 📄 Supportaci — PDF Guide: store.hackerslegacy.com ⚠️ AVVISO: Tutti gli strumenti sono destinati esclusivamente a programmi di bug bounty autorizzati, ricerca etica sulla sicurezza e penetration testing con esplicita autorizzazione scritta. L'uso non autorizzato è illegale. L'uso etico è obbligatorio. 📌 Quale di questi 7 installerai per primo sul tuo telefono? Scrivilo nei commenti! 🔔 Iscriviti per ricevere contenuti settimanali su strumenti Termux, hacking Android e hacking etico. Non sponsorizzato. Tutti gli strumenti sono gratuiti e open source. Solo per uso autorizzato. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [iw] 7 כלי האקינג סודיים מ-GitHub ל-Termux עבור האקרים אתיים 2026 📱 7 כלי פריצה סודיים של Termux ב-GitHub עבור האקרים לאנדרואיד 2026 | פריצה אתית באנדרואיד רוב האנשים מתקינים את Termux, מפעילים nmap פעם אחת ועוצרים שם. האנשים שבאמת יודעים למה Termux מסוגלת הם כלים שסורקים יישומי אינטרנט עם רינדור JavaScript, מוצאים אוטומטית כל כתובת URL שהייתה אי פעם לדומיין מארכיונים ציבוריים, צדים מפתחות API שדלפו הקבורים בהיסטוריית commit של GitHub, ומפעילים התקפות XSS בתבונה רבה יותר מרוב סורקי שולחן העבודה. 7 הכלים הללו נמצאים כולם ב-GitHub, כולם פועלים באנדרואיד דרך Termux, וכולם משמשים ציידי ראשי באגים, האקרים אתיים ובודקי חדירה בהערכות אבטחה מורשים ברחבי העולם. בין אם אתם לומדים ל-OSCP, CEH, בונים ערכת כלים לצוות אדום נייד, או מבצעים ציד באגים מורשה מטלפון האנדרואיד שלכם - 7 הכלים האלה מעלים את מה ש-Termux יכול לעשות בשנת 2026. 🔴 כל 7 הכלים: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → סורק XSS חכם | בחירת מטען מודעת להקשר | ניתוח DOM | מצב XSS עיוור | מבוסס GO, מהיר | העברת קוד עם GAU לגילוי XSS אוטומטי ✅ #2 — GAU (github.com/lc/gau) → קבל את כל כתובות ה-URL — Wayback Machine, OTX, URLScan וסריקה משותפת | גילוי כתובות URL היסטוריות | מציאת נקודות קצה שנמחקו ופאנלים ישנים של ניהול | העברת קוד ל-Dalfox ולסורקים אחרים ✅ #3 — Katana (github.com/projectdiscovery/katana) → סורק אינטרנט מהדור הבא | רינדור JS של דפדפן ללא ראש | מציאת נקודות קצה נסתרות וקריאות API | מצבים פעילים + פסיביים | מאת ProjectDiscovery | הזנת סורקי באגים ✅ #4 — Photon (github.com/s0md3v/Photon) → סורק רשת OSINT | מחלץ מיילים, קישורים, מפתחות API בקבצי JS, תת-דומיינים ותגובות | איסוף מודיעין גילוי מורשה | מהיר וקל משקל ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → סורק גילוי ופגיעויות הכל-באחד | IP, WHOIS, תת-דומיינים, פורטים, זיהוי CMS, SQLi, XSS וניתוח כותרות | בדיקות פגיעויות בוורדפרס וג'ומלה | ממשק תפריט יחיד ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → סורק היסטוריית קומיטים ומאגרים של GitHub עבור סודות שדלפו | מפתחות API, טוקנים, אישורי AWS, סיסמאות | מוצא סודות שנמחקו בקומיטים מאוחרים יותר | מכרה זהב של באגים באונטי ✅ #7 — XSStrice (github.com/s0md3v/XSStrice) → חבילת זיהוי XSS המתקדמת ביותר ב-GitHub | יצירת מטען ספציפי להקשר | זיהוי ועקיפת WAF | סורק DOM XSS | כלולים Fuzzer ו-crawler 🔗 כל הקישורים ל-GITHUB: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrice: s0md3v/XSStrice 💼 חסויות ועסקים: sponsors.hackerslegacy.com 📚 בלוגים של אבטחת סייבר: hackerslegacy.com 📄 תמכו בנו — מדריכי PDF: store.hackerslegacy.com ⚠️ הצהרת אחריות: כל הכלים מיועדים לתוכניות באגים מורשות, מחקר אבטחה אתי ובדיקות חדירה עם הוראות כתובות מפורשות רק באישור. שימוש לא מורשה אינו חוקי. תמיד שימוש אתי. 📌 איזה מבין 7 אלה מופעל על הטלפון שלך ראשון? כתבו בתגובות! 🔔 הירשמו לקבלת תוכן שבועי על כלי Termux, פריצה לאנדרואיד ותוכן פריצה אתית. לא ממומן. כל הכלים בחינם ובקוד פתוח. שימוש מורשה בלבד. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [ja] エシカルハッカーのためのTermux GitHubハッキングツール7選【2026年版】 📱 AndroidハッカーのためのTermuxとGitHubを使った秘密のハッキングツール7選（2026年版）｜Androidにおける倫理的ハッキング 多くの人はTermuxをインストールし、nmapを一度実行したらそこで止まってしまいます。しかし、Termuxの真の能力を理解している人たちは、JavaScriptレンダリングされたWebアプリケーションをクロールしたり、公開アーカイブからドメインの過去のすべてのURLを自動的に検索したり、GitHubのコミット履歴に埋もれたAPIキーを探し出したり、ほとんどのデスクトップスキャナーよりも高度なXSS攻撃を実行したりするツールを活用しています。 これらの7つのツールはすべてGitHub上にあり、すべてTermuxを介してAndroid上で動作し、世界中のバグバウンティハンター、倫理的ハッカー、ペネトレーションテスターが、公認のセキュリティ評価で使用しています。 OSCPやCEHの勉強をしている方、モバイルレッドチームツールキットを構築している方、Androidスマートフォンから認可されたバグバウンティハンティングを行っている方など、これらの7つのツールは、2026年のTermuxの可能性を大きく広げます。 🔴 7つのツールすべて： ✅ #1 — Dalfox (github.com/hahwul/dalfox) → スマートXSSスキャナー | コンテキスト認識ペイロード選択 | DOM解析 | ブラインドXSSモード | Goベースで高速 | GAUと連携してXSSを自動検出 ✅ #2 — GAU (github.com/lc/gau) → すべてのURLを取得 — Wayback Machine、OTX、URLScan、Common Crawl | 履歴URL検出 | 削除されたエンドポイントと古い管理パネルを検出 | Dalfoxや他のスキャナーと連携 ✅ #3 — Katana (github.com/projectdiscovery/katana) → 次世代Webクローラー | ヘッドレスブラウザJSレンダリング | 隠されたエンドポイントとAPI呼び出しを検出 |アクティブモードとパッシブモード | ProjectDiscovery提供 | バグバウンティスキャナーに情報を提供 ✅ #4 — Photon (github.com/s0md3v/Photon) → OSINTウェブクローラー | JSファイル、サブドメイン、コメントからメールアドレス、リンク、APIキーを抽出 | 認証済み偵察情報収集 | 高速かつ軽量 ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → オールインワンのウェブ偵察＆脆弱性スキャナー | IPアドレス、WHOIS情報、サブドメイン、ポート番号、CMS検出、SQLインジェクション、XSS、ヘッダー分析 | WordPressとJoomlaの脆弱性チェック | シングルメニューインターフェース ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → GitHubリポジトリとコミット履歴をスキャンして漏洩したシークレットを検出 | APIキー、トークン、AWS認証情報、パスワード | 後続のコミットで削除されたシークレットも検出 |バグ報奨金の宝庫 ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → GitHub上で最も高度なXSS検出スイート | コンテキストに応じたペイロード生成 | WAF検出とバイパス | DOM XSSスキャナー |ファザーとクローラーが含まれています 🔗 すべてのGitHubリンク: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 スポンサーシップとビジネス: sponsors.hackerslegacy.com 📚 サイバーセキュリティブログ: hackerslegacy.com 📄 サポート — PDFガイド: store.hackerslegacy.com ⚠️ 免責事項: すべてのこれらのツールは、正式な書面による許可を得た上で、認可されたバグバウンティプログラム、倫理的なセキュリティ研究、およびペネトレーションテストにのみ使用できます。無断使用は違法です。常に倫理的な使用を心がけてください。 📌 これらの7つのうち、どれを最初にあなたのスマホにインストールしますか？コメント欄で教えてください！ 🔔 毎週配信されるTermuxツール、Androidハッキング、倫理的ハッキングに関するコンテンツを購読してください。 スポンサー提供ではありません。すべてのツールは無料かつオープンソースです。許可された使用のみ。 #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #Cyber​​Security [ko] 윤리적 해커를 위한 7가지 비밀 Termux GitHub 해킹 도구 2026 📱 안드로이드 해커를 위한 7가지 비밀 Termux GitHub 해킹 도구 (2026년) | 안드로이드 윤리적 해킹 대부분의 사람들은 Termux를 설치하고 nmap을 한 번 실행한 후 더 이상 활용하지 않습니다. 하지만 Termux의 진정한 잠재력을 아는 사람들은 JavaScript 렌더링을 사용하는 웹 애플리케이션을 크롤링하고, 공개 아카이브에서 특정 도메인이 이전에 사용했던 모든 URL을 자동으로 찾아내고, GitHub 커밋 기록에 숨겨진 유출된 API 키를 추적하고, 대부분의 데스크톱 스캐너보다 더 지능적인 XSS 공격을 실행하는 도구를 사용합니다. 이 7가지 도구는 모두 GitHub에서 찾을 수 있으며, Termux를 통해 안드로이드에서 실행되고, 전 세계의 버그 바운티 헌터, 윤리적 해커, 침투 테스터들이 공인 보안 평가에 활용하고 있습니다. OSCP, CEH 시험을 준비하든, 모바일 레드팀 툴킷을 구축하든, 안드로이드 폰으로 버그 바운티 헌팅을 하든, 이 7가지 도구는 2026년 Termux의 활용도를 한 단계 끌어올려 줍니다. 🔴 7가지 도구 모두 보기: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → 스마트 XSS 스캐너 | 컨텍스트 인식 페이로드 선택 | DOM 분석 | 블라인드 XSS 모드 | Go 기반, 빠른 속도 | GAU와 연동하여 자동 XSS 탐지 ✅ #2 — GAU (github.com/lc/gau) → 모든 URL 가져오기 — Wayback Machine, OTX, URLScan 및 Common Crawl 활용 | 과거 URL 검색 | 삭제된 엔드포인트 및 이전 관리자 패널 찾기 | Dalfox 및 기타 스캐너와 연동 ✅ #3 — Katana (github.com/projectdiscovery/katana) → 차세대 웹 크롤러 | 헤드리스 브라우저 JS 렌더링 | 숨겨진 엔드포인트 및 API 호출 찾기 | 능동 및 수동 모드 지원 | ProjectDiscovery 제작 | 버그 바운티 스캐너에 피드 제공 ✅ #4 — Photon (github.com/s0md3v/Photon) → OSINT 웹 크롤러 | JS 파일, 서브도메인 및 댓글에서 이메일, 링크, API 키 추출 | 권한 있는 정찰 정보 수집 | 빠르고 가벼움 ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → 올인원 웹 정찰 및 취약점 스캐너 | IP, WHOIS, 서브도메인, 포트, CMS 탐지, SQLi, XSS 및 헤더 분석 | WordPress 및 Joomla 취약점 검사 | 단일 메뉴 인터페이스 ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → GitHub 리포지토리 및 커밋 기록에서 유출된 비밀 정보 검색 | API 키, 토큰, AWS 자격 증명, 비밀번호 | 이후 커밋에서 삭제된 비밀 정보 검색 | 버그 바운티 보물창고 ✅ #7 — XSStrike (github.com/s0md3v/XSStrike) → GitHub에서 가장 진보된 XSS 탐지 도구 모음 | 상황별 페이로드 생성 | WAF 탐지 및 우회 | DOM XSS 스캐너 | 퍼저 및 크롤러 포함 🔗 모든 깃허브 링크: → Dalfox: hahwul/dalfox → GAU: lc/gau → Katana: projectdiscovery/katana → Photon: s0md3v/Photon → Red Hawk: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 후원 및 비즈니스: sponsors.hackerslegacy.com 📚 사이버 보안 블로그: hackerslegacy.com 📄 후원하기 — PDF 가이드: store.hackerslegacy.com ⚠️ 면책 조항: 모든 도구는 승인된 버그 바운티 프로그램, 윤리적 보안 연구 및 침투 테스트 용도로만 사용 가능하며, 명시적인 서면 허가를 받은 경우에만 사용할 수 있습니다. 무단 사용은 불법입니다. 항상 윤리적인 사용을 지향하세요. 📌 이 7가지 도구 중 어떤 것을 먼저 설치하시겠습니까? 댓글로 알려주세요! 🔔 매주 Termux 도구, Android 해킹 및 윤리적 해킹 관련 콘텐츠를 받아보시려면 구독하세요. 광고 아님. 모든 도구는 무료 오픈 소스입니다. 허가된 용도로만 사용하십시오. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [ml] എത്തിക്കൽ ഹാക്കർമാർക്കായി 7 രഹസ്യ Termux GitHub ഹാക്കിംഗ് ടൂളുകൾ 2026 📱 ആൻഡ്രോയിഡ് ഹാക്കർമാർക്കുള്ള 7 രഹസ്യ ടെർമക്സ് ഗിറ്റ്ഹബ് ഹാക്കിംഗ് ടൂളുകൾ 2026 | ആൻഡ്രോയിഡിലെ എത്തിക്കൽ ഹാക്കിംഗ് മിക്ക ആളുകളും ടെർമക്സ് ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ഒരിക്കൽ nmap പ്രവർത്തിപ്പിക്കുന്നു, അവിടെ നിർത്തുന്നു. ടെർമക്സിന് എന്താണ് കഴിവുള്ളതെന്ന് യഥാർത്ഥത്തിൽ അറിയുന്ന ആളുകൾ ജാവാസ്ക്രിപ്റ്റ് റെൻഡറിംഗ് ഉപയോഗിച്ച് വെബ് ആപ്ലിക്കേഷനുകൾ ക്രാൾ ചെയ്യുന്ന, പൊതു ആർക്കൈവുകളിൽ നിന്ന് ഒരു ഡൊമെയ്‌നിന് ഇതുവരെ ലഭിച്ചിട്ടുള്ള എല്ലാ URL-ഉം സ്വയമേവ കണ്ടെത്തുന്ന, GitHub കമ്മിറ്റ് ഹിസ്റ്ററിയിൽ കുഴിച്ചിട്ടിരിക്കുന്ന ചോർന്ന API കീകൾ വേട്ടയാടുന്ന, മിക്ക ഡെസ്‌ക്‌ടോപ്പ് സ്‌കാനറുകളേക്കാളും കൂടുതൽ ബുദ്ധിയോടെ XSS ആക്രമണങ്ങൾ നടത്തുന്ന ടൂളുകളാണ് പ്രവർത്തിപ്പിക്കുന്നത്. ഈ 7 ടൂളുകളും GitHub-ലാണ്, എല്ലാം ടെർമക്സ് വഴി ആൻഡ്രോയിഡിൽ പ്രവർത്തിക്കുന്നു, കൂടാതെ ലോകമെമ്പാടുമുള്ള അംഗീകൃത സുരക്ഷാ വിലയിരുത്തലുകളിൽ ബഗ് ബൗണ്ടി ഹണ്ടർമാർ, നൈതിക ഹാക്കർമാർ, പെനട്രേഷൻ ടെസ്റ്റർമാർ എന്നിവർ എല്ലാം ഉപയോഗിക്കുന്നു. നിങ്ങൾ OSCP, CEH എന്നിവയ്‌ക്കായി പഠിക്കുകയാണെങ്കിലും, ഒരു മൊബൈൽ റെഡ് ടീം ടൂൾകിറ്റ് നിർമ്മിക്കുകയാണെങ്കിലും, അല്ലെങ്കിൽ നിങ്ങളുടെ Android ഫോണിൽ നിന്ന് അംഗീകൃത ബഗ് ബൗണ്ടി ഹണ്ടിംഗ് നടത്തുകയാണെങ്കിലും - ഈ 7 ടൂളുകൾ 2026-ൽ Termux-ന് ചെയ്യാൻ കഴിയുന്നതിനേക്കാൾ മികച്ച നിലവാരം പുലർത്തുന്നു. 🔴 എല്ലാ 7 ടൂളുകളും: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → സ്മാർട്ട് XSS സ്കാനർ | സന്ദർഭ-അവബോധമുള്ള പേലോഡ് തിരഞ്ഞെടുക്കൽ | DOM വിശകലനം | ബ്ലൈൻഡ് XSS മോഡ് | ഗോ-അധിഷ്ഠിതം, വേഗത | ഓട്ടോമേറ്റഡ് XSS കണ്ടെത്തലിനായി GAU ഉള്ള പൈപ്പുകൾ ✅ #2 — GAU (github.com/lc/gau) → എല്ലാ URL-കളും നേടുക — വേബാക്ക് മെഷീൻ, OTX, URLScan & Common Crawl | ചരിത്രപരമായ URL കണ്ടെത്തൽ | ഇല്ലാതാക്കിയ എൻഡ്‌പോയിന്റുകളും പഴയ അഡ്മിൻ പാനലുകളും കണ്ടെത്തുന്നു | Dalfox-ലേക്കും മറ്റ് സ്കാനറുകളിലേക്കും പൈപ്പുകൾ ✅ #3 — Katana (github.com/projectdiscovery/katana) → അടുത്ത തലമുറ വെബ് ക്രാളർ | ഹെഡ്‌ലെസ് ബ്രൗസർ JS റെൻഡറിംഗ് | മറഞ്ഞിരിക്കുന്ന എൻഡ്‌പോയിന്റുകളും API കോളുകളും കണ്ടെത്തുന്നു | സജീവ + നിഷ്ക്രിയ മോഡുകൾ | ProjectDiscovery വഴി | ബഗ് ബൗണ്ടി സ്കാനറുകൾ ഫീഡ് ചെയ്യുന്നു ✅ #4 — ഫോട്ടോൺ (github.com/s0md3v/Photon) → OSINT വെബ് ക്രാളർ | JS ഫയലുകളിലെയും സബ്ഡൊമെയ്‌നുകളിലെയും ഇമെയിലുകൾ, ലിങ്കുകൾ, API കീകൾ എന്നിവ എക്‌സ്‌ട്രാക്‌റ്റ് ചെയ്യുന്നു, സബ്ഡൊമെയ്‌നുകളിലും കമന്റുകളിലും | അംഗീകൃത റീകൺ ഇന്റലിജൻസ് ശേഖരണം | വേഗതയേറിയതും ഭാരം കുറഞ്ഞതും ✅ #5 — റെഡ് ഹോക്ക് (github.com/Tuhinshubhra/RED_HAWK) → ഓൾ-ഇൻ-വൺ വെബ് റീകൺ & വൾനറബിലിറ്റി സ്കാനർ | IP, WHOIS, സബ്ഡൊമെയ്‌നുകൾ, പോർട്ടുകൾ, CMS ഡിറ്റക്ഷൻ, SQLi, XSS & ഹെഡർ വിശകലനം | വേർഡ്പ്രസ്സ് & ജൂംല വൾൺ ചെക്കുകൾ | സിംഗിൾ മെനു ഇന്റർഫേസ് ✅ #6 — TruffleHog (github.com/trufflesecurity/trufflehog) → ചോർന്ന രഹസ്യങ്ങൾക്കായി GitHub ശേഖരങ്ങളും കമ്മിറ്റ് ചരിത്രവും സ്കാൻ ചെയ്യുന്നു | API കീകൾ, ടോക്കണുകൾ, AWS ക്രെഡൻഷ്യലുകൾ, പാസ്‌വേഡുകൾ | പിന്നീടുള്ള കമ്മിറ്റുകളിൽ ഇല്ലാതാക്കിയ രഹസ്യങ്ങൾ കണ്ടെത്തുന്നു | ബഗ് ബൗണ്ടി ഗോൾഡ്‌മൈൻ ✅ #7 — XSSstrike (github.com/s0md3v/XSSstrike) → GitHub-ലെ ഏറ്റവും നൂതനമായ XSS ഡിറ്റക്ഷൻ സ്യൂട്ട് | സന്ദർഭ-നിർദ്ദിഷ്ട പേലോഡ് ജനറേഷൻ | WAF ഡിറ്റക്ഷനും ബൈപാസും | DOM XSS സ്കാനർ | ഫസ്സറും ക്രാളറും ഉൾപ്പെടുന്നു 🔗 എല്ലാ GITHUB ലിങ്കുകളും: → Dalfox: hahwul/dalfox → GAU: lc/gau → കറ്റാന: projectdiscovery/katana → ഫോട്ടോൺ: s0md3v/Photon → റെഡ് ഹോക്ക്: Tuhinshubhra/RED_HAWK → TruffleHog: trufflesecurity/trufflehog → XSStrike: s0md3v/XSStrike 💼 സ്പോൺസർഷിപ്പുകളും ബിസിനസ്സും: sponsors.hackerslegacy.com 📚 സൈബർ സുരക്ഷ ബ്ലോഗുകൾ: hackerslegacy.com 📄 ഞങ്ങളെ പിന്തുണയ്ക്കുക — PDF ഗൈഡുകൾ: store.hackerslegacy.com ⚠️ നിരാകരണം: എല്ലാ ഉപകരണങ്ങളും അംഗീകൃത ബഗ് ബൗണ്ടിക്ക് വേണ്ടിയുള്ളതാണ് പ്രോഗ്രാമുകൾ, നൈതിക സുരക്ഷാ ഗവേഷണം, പെനെട്രേഷൻ ടെസ്റ്റിംഗ് എന്നിവ വ്യക്തമായ രേഖാമൂലമുള്ള അനുമതിയോടെ മാത്രം. അനധികൃത ഉപയോഗം നിയമവിരുദ്ധമാണ്. നൈതിക ഉപയോഗം എപ്പോഴും. 📌 ഈ 7 എണ്ണത്തിൽ ഏതാണ് നിങ്ങളുടെ ഫോണിൽ ആദ്യം പോകുന്നത്? അഭിപ്രായങ്ങളിൽ ഇടുക! 🔔 പ്രതിവാര ടെർമക്സ് ടൂളുകൾ, ആൻഡ്രോയിഡ് ഹാക്കിംഗ്, നൈതിക ഹാക്കിംഗ് ഉള്ളടക്കം എന്നിവയ്ക്കായി സബ്‌സ്‌ക്രൈബുചെയ്യുക. സ്പോൺസർ ചെയ്തിട്ടില്ല. എല്ലാ ടൂളുകളും സൗജന്യവും ഓപ്പൺ സോഴ്‌സും. അംഗീകൃത ഉപയോഗം മാത്രം. #Termux #AndroidHacking #EthicalHacking #BugBounty #GitHub #HackingTools2026 #XSS #TruffleHog #Dalfox #CyberSecurity [nl-NL] 7 Geheime Termux GitHub Hacking Tools Voor Ethische Hackers 2026 📱 7 geheime Termux GitHub-hacktools voor Android-hackers in 2026 | Ethisch hacken op Android De meeste mensen installeren Termux, draaien nmap een keer en stoppen daar. De mensen die echt weten waartoe Termux in staat is, gebruiken tools die webapplicaties met JavaScript-rendering crawlen, automatisch elke URL vinden die een domein ooit heeft gehad in openbare archieven, gelekte API-sleutels opsporen die verborgen liggen in GitHub-commitgeschiedenissen en XSS-aanvallen uitvoeren die intelligenter zijn dan de meeste desktopscanners. Deze 7 tools zijn allemaal te vinden op GitHub, draaien allemaal op Android via Termux en worden allemaal gebruikt door bug bounty hunters, ethische hackers en penetratietesters bij geautoriseerde beveiligingsbeoordelingen wereldwijd. Of je nu studeert voor OSCP of CEH, een mobiele red team toolkit bouwt of geautoriseerde bug bounty hunting uitvoert vanaf je Android-telefoon — deze 7 tools tillen de mogelijkheden van Termux naar een hoger niveau in 2026. 🔴 ALLE 7 TOOLS: ✅ #1 — Dalfox (github.com/hahwul/dalfox) → Slimme XSS-scanner | Contextbewuste payloadselectie | DOM-analyse | Blinde XSS-modus | Op Go gebaseerd, snel | Kan worden gekoppeld aan GAU voor geautomatiseerde XSS-detectie ✅ #2 — GAU (github.com/lc/gau) → Get All URLs — Wayback Machine, OTX, URLScan & Common Crawl | Ontdekking van historische URL's | Vindt verwijderde endpoints en oude adminpanelen | Kan worden gekoppeld aan Dalfox en andere scanners ✅ #3 — Katana (github.com/projectdiscovery/katana) → Webcrawler van de volgende generatie | Headless browser JS-rendering | Vindt verborgen endpoints en API-aanroepen | Actieve + passieve modus | Door ProjectDiscovery | Voedt bug bounty scanners ✅ #4 — Photon (github.com/s0md3v/Photon) → OSINT-webcrawler | Extraheert e-mails, links, API-sleutels in JS-bestanden, subdomeinen en reacties | Verzamelt geautoriseerde inlichtingen via verkenning | Snel en lichtgewicht ✅ #5 — Red Hawk (github.com/Tuhinshubhra/RED_HAWK) → Alles-in-één webverkenning- en kwetsbaarheidsscanner | IP-, WHOIS-, subdomein-, poort- en CMS-detectie, SQLi-, XSS- en headeranalyse | Kwetsbaarheidscontroles voor WordPress en Joomla | E

3) It finds your leaked passwords TruffleHog scans your code and files for passwords and API keys you left lying around, and checks which ones still work. 28,000 stars. trufflesecurity/trufflehog

Borraste tu clave de AWS de GitHub… pero sigue ahí Borrar una clave de AWS de tu repositorio no la elimina: Git guarda todo el historial y la clave sigue en commits anteriores. En este vídeo uso TruffleHog, una herramienta open source que analiza el historial completo de un repo, detecta secretos y verifica si siguen activos. Comando de la demo: trufflehog git trufflesecurity/test_keys --results=verified Repositorio de TruffleHog: trufflesecurity/trufflehog Qué hacer si te pasa: 1. Rotar la clave inmediatamente 2. Revisar CloudTrail para ver si se ha usado 3. Configurar TruffleHog como pre-commit ¿Lo has pasado alguna vez por tus repos? #AWS #GitHub #SeguridadCloud #DevSecOps #Shorts [en-US] You deleted your AWS key from GitHub… but it's still there Deleting an AWS key from your repository doesn't actually remove it: Git keeps a complete history, and the key remains in previous commits. In this video, I use TruffleHog, an open-source tool that analyzes a repository's entire history, detects secrets, and verifies if they are still active. Demo command: `trufflehog git trufflesecurity/test_keys --results=verified` TruffleHog repository: trufflesecurity/trufflehog What to do if this happens: 1. Rotate the key immediately. 2. Check CloudTrail to see if it has been used. 3. Configure TruffleHog as a pre-commit tool. Have you ever encountered this issue with your repositories? #AWS #GitHub #CloudSecurity #DevSecOps #Shorts

AI Agents Broke Into 100+ Sites at About $50 Each. The Confirmed One Used Old PHP Flaws - Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- One operator, fewer than 100 Chinese characters of instructions, and roughly $5,000 in tokens. By the estimate Reuters reported on October 19 (via BNN Bloomberg), that was enough for AI agents to break into websites belonging to more than 100 companies, at around $50 in tokens per successful hack. The same day, the security firm NorForge published Inside Cairn, a report on more than 20 AI "hacking" control panels it found sitting open on the public internet. Reuters named Deere, SharkNinja and Cummins among the victims. Deere said it had taken remediation actions and saw no sign that sensitive data was accessed. SharkNinja said a standalone product-support site was hit and the threat contained. Cummins said it was investigating a report of a potential attack on a website run by one of its third-party vendors. The detail that matters more for you is how they got in. NorForge verified one intrusion by fetching the web shell the agents left behind. By the agent's own log, that break-in used no new or clever exploit. It ran through a memcached session store the attacker could write to, an unsafe PHP unserialize() call, and a gadget chain in legacy Zend Framework components. Each of those has been a known footgun for years. A control panel on port 8000, open to anyone The tool in the story is Cairn, an open-source "general-purpose problem-solving engine" that was first validated on autonomous penetration testing. It is AGPLv3, it runs coding-agent CLIs like Claude Code, Codex and Pi as its workers, and its README is explicit that you must have "clear prior permission from the owner or operator" before pointing it at anything. It is a red-team tool with legitimate uses. What NorForge documents is operators leaving the tool's web panel exposed. It found the panels by scanning with Shodan and Censys, grouped them into three clusters by shared targeting and instructions, and assessed all three as malicious, two with high confidence. Every panel in its indicator list was reachable on port 8000. Some were protected against unauthorized access; others "appear completely unprotected," showing what looked like full administrative control to anyone who browsed to the address. Docker is one common way this happens. Cairn's own Docker Compose setup starts its server on port 8000, and Docker's docs warn that publishing container ports is insecure by default: a plain -p 8000:8000 publishes to all host addresses (0.0.0.0 and [::]), so the port "becomes available not only to the Docker host, but to the outside world as well," and your laptop is only one of the machines that can reach it. The fix is one prefix: # Reachable only from this machine docker run -p 127.0.0.1:8000:8000 my-agent-panel However these operators exposed theirs, the result was the same: NorForge read much of their operation off the open panels, down to the target lists and the agents' own notes on what they found. The one verified break-in used old PHP NorForge was careful not to claim it broke into anything. To check that one claimed intrusion was real, it fetched the URL of an "uploader" web shell the agents had left on a large hardware-parts vendor, and the shell was there. The report does not say NorForge used it. The account of how the agents got in comes from the agent's own explanation in its task log. The chain, as that log tells it: the agents found a memcached session store they could write to, poisoned a serialized session value, and triggered PHP object injection through a gadget chain in legacy framework code. memcached's own docs say plainly, "you _must not_ expose memcached directly to the internet, or otherwise any untrusted users," and add that the server spends little, if any, effort defending itself from random internet connections. PHP's unserialize() manual opens with a warning: "Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes." PHPGGC, a public library of ready-made unserialize() payloads that includes Zend Framework chains, was among the tools NorForge found in an agent worker folder. What was new was who did the trying. In NorForge's main cluster, projects that reached their goal took "a little under 23 hours" on average from start to goal, and each project logged around 140 facts on average, grinding through a target until a boring flaw lined up. Why your unserialize() and your memcached are the target The pattern to defend against is a shop whose oldest code still trusts its own serialized data. To close the door NorForge described: - Never unserialize() untrusted bytes. Session values read back from a shared store count as untrusted the moment that store is reachable by anyone else. The manual's own advice is to move to a format with no object instantiation: json_encode() / json_decode(). Setting allowed_classes => false is not a fix; php.net tells you to keep untrusted input away from unserialize() "regardless of the options value of allowed_classes." - Don't expose your session store. memcached and Redis bind where you tell them to. Keep them on 127.0.0.1 or a private network, and treat any internet-reachable cache as already compromised. - Retire the legacy framework code that carries the gadgets. The gadget chain lived in old Zend Framework components. Gadget chains come from what your framework leaves on the autoload path, so code you no longer use stays attack surface until you delete it. Decoupling pays off on the last one. When your domain logic sits behind a thin port instead of inside framework classes, a dead framework version is a dependency you can remove with a composer change and a few adapters, and the rest of the app does not notice. Don't put your own agent panels on the open internet There is a direct lesson for anyone running coding agents, even if nobody is targeting you. Cairn's workers are the same CLIs many of us run every day. DeepSeek even documents pointing Claude Code at its own API by setting ANTHROPIC_BASE_URL, which fits the worker name NorForge saw, claudecode_deepseek-v4.1-flash, and Reuters' report that the campaign used a mix of DeepSeek and Claude Code. So the surface that got these operators caught is the same surface you create when you stand up any agent control plane, task queue or run dashboard and forward a port to "just check it from my phone." Keep it on localhost, behind a VPN or an authenticating proxy. Assume anything on 0.0.0.0 will be indexed. I build Hermes IDE, so weigh this with that in mind. Hermes is a desktop app: each agent runs in its own terminal and each task on its own hermes/<name> branch and worktree. It is free and source-available (BSL 1.1), on macOS, Windows and Linux. None of that is a security guarantee, and the point stands for whatever you run. What actually changed The techniques in this story are a decade old. The economics are not. Reuters reports the agents went after more than 1,200 sites largely without human intervention, with the operator doing almost none of the work. NorForge estimates the average cost of a single task at about $5, counting the failures, and the overall success rate at around 10%, and says the cost figure carries considerable uncertainty. A 10% hit rate is fine for a loop that costs $5 a swing. The boring flaw you deprioritized because "who would bother" is now worth bothering with, at volume, by something that does not get tired. NorForge also found hundreds of secrets in the exposed panel data, with Trufflehog verifying 11% as still valid. And it found that legitimate red teams had put real customer penetration tests on unsecured panels of their own. --- If this was useful The flaw in this story was legacy framework code that still trusted its own serialized data. You keep that kind of code from becoming load-bearing by keeping the framework at the edge: domain logic behind ports, framework classes as adapters you can swap or delete. Decoupled PHP covers clean and hexagonal architecture for PHP applications that outlive their framework, which is how an old Zend component ends up as a composer change and a few adapters instead of a migration project. If you also run coding agents, Hermes IDE (GitHub) gives each one its own terminal and its own branch.  Available on Kindle, Paperback, and Hardcover. English, German, and Japanese editions out now — Portuguese and Spanish coming soon.

The First Cut: How Module Boundaries Get Drawn and Why They Drift Part 2 of the Production Codebase series. New here? Start with Part 1. Software Architecture from First Principles — Part 2: Monolithic Entanglement, Coupling Mathematics, and Language-Enforced Boundaries --- The Thirty-Second Test Clone a healthy production repository, open the root directory in your editor, and inspect the file tree. Within thirty seconds, without inspecting a single function or reading a single implementation file, the operational reality of the system reveals itself. You know where domain business logic lives, where tests are segregated, which team owns the payment processor, how to spin up dependencies locally, which environment variables are mandatory, and how database migrations are sequenced. You have not sent a single message on Slack. You have not interrupted a tech lead. The physical structure of the repository answered your questions before you had to ask them. In the first article, we established that folder structure is a system design decision — shaped by Conway's Law, forcing functions, and team communication patterns. We introduced the fintech engine and promised to open it. This is that article. Now open the other kind of repository. Forty-three files sit strewn across the top-level directory. You see FEATURE_240_DESCRIPTION.md, analytics.ts, fin.java, and IMPLEMENTATION_COMPLETE_SUMMARY.md mixed directly alongside package.json and tsconfig.json. Three separate docker-compose files exist with names like docker-compose.local.yml, docker-compose.dev.backup.yml, and docker-compose.final.yml, none of which document which one actually works. The .env.example file contains stale database credentials from four years ago that reference a Postgres instance that was migrated to Amazon Aurora during the pandemic. You do not begin coding. You close your terminal, open Slack, and ask who knows how to run this project. The difference between those two repositories has nothing to do with the algorithmic brilliance of the code inside them. It has everything to do with whether the engineers who built the system treated the root directory as an intentional architectural contract or as an unmonitored staging ground for sprint artifacts. fintech-engine/ ├── .github/ # CI workflows and templates │ ├── workflows/ # Validation and deployment pipelines │ └── pull_request_template.md ├── .gitignore # Source control boundary ├── .dockerignore # Build context filter ├── .env.example # Local execution contract ├── CODEOWNERS # Ownership and compliance control ├── LICENSE ├── README.md # Entry point and setup guide ├── CHANGELOG.md # Human-readable change history ├── justfile # Task runner interface ├── docker-compose.yml # Local dependency topology ├── docs/ │ ├── adr/ # Immutable decision records │ ├── architecture/ # System maps and diagrams │ ├── onboarding/ # New engineer ramp-up guides │ └── runbooks/ # Incident playbooks ├── infra/ │ ├── terraform/ # Cloud resource provisioning │ └── k8s/ # Container scheduling manifests ├── migrations/ # Immutable schema scripts ├── scripts/ │ ├── local/ # Workstation scripts │ └── ci/ # Pipeline scripts ├── src/ # Application source code └── tests/ ├── unit/ # Fast in-memory tests ├── integration/ # Database and broker tests └── e2e/ # End-to-end journey tests --- The Locational Predictability Imperative There is an unspoken assumption among junior developers that good engineers read every line of code in the systems they maintain. In a real production system containing one hundred thousand or five hundred thousand lines of code, nobody reads every line of code. Tech leads, staff architects, and on-call responders survive by reading almost none of it. They navigate systems by forming coarse mental maps of ownership, boundaries, and lifecycles, diving into precise implementation lines only when an incident strikes or a specific interface requires extension. Empirical software engineering research confirms this reality. In their landmark study on developer activity, I Know What You Did Last Summer: An Investigation on How Developers Spend Their Time, researchers Roberto Minelli, Andrea Mocci, and Michele Lanza tracked developers across professional tasks and discovered that programmers spend 58 to 70 percent of their working time comprehending, navigating, and inspecting codebases, while spending only 5 percent of their time actively editing or typing code. Decades earlier, Robert C. Martin observed in Clean Code that the ratio of time spent reading code versus writing code exceeds ten to one. When a junior engineer submits a pull request introducing a new merchant discount rule, a senior reviewer should not have to execute a full-text search across fifty directories to determine where the logic was placed. A well-designed codebase exhibits locational predictability: given a business domain concept or a bug description, any experienced engineer should be able to deduce the exact directory, file, and interface where the modification belongs before opening the file tree. When a codebase lacks locational predictability, every code review becomes an archaeological expedition, and the seventy-percent navigation tax compounds into organizational paralysis. --- The Physical Geography of Repository Contracts The root of a production repository houses the physical contracts governing how code is built, tested, and audited, beginning with src/ to isolate application domain logic from development scaffolding. Yet treating src/ as a universal convention overlooks other language ecosystems. In Go repositories, binaries live in cmd/ while internal libraries reside in internal/. Introduced by Russ Cox in Go 1.4, any package inside an internal/ directory is mechanically restricted by the compiler: packages outside the immediate parent hierarchy cannot import it. While teams working in TypeScript or Python frequently rely on fragile lint rules that erode under sprint panic, Go turns directory placement into a compiler-enforced boundary. Database transformations inside migrations/ operate under a single non-negotiable law: applied migrations are immutable. Once a schema migration script is merged to the main branch and executed against any shared environment, that file must never be modified. Migration frameworks like Flyway enforce this discipline by calculating cryptographic checksums of every script and verifying them against a history ledger table, aborting deployments if a single byte has changed. To manage zero-downtime schema evolution safely across rolling releases without table-locking outages, teams apply the expand-contract pattern formalized by Pramod Sadalage and Martin Fowler, decoupling schema expansions, dual-writing code deployments, data backfills, and contracting column removals into distinct, non-breaking phases. Repository governance centers around CODEOWNERS, which performs three simultaneous architectural jobs. First, it routes pull requests to designated domain experts based on path matching. Second, it acts as a regulatory compliance control for Segregation of Duties (SoD) under Section 404 of the Sarbanes-Oxley Act (SOX) and SOC 2 Type II Common Criteria CC6.1, mathematically preventing authors from self-approving changes to sensitive financial calculation or authorization paths. Third, it serves as an automated blast-radius audit: any directory lacking an explicit code owner represents an unmonitored path that can bypass mandatory security and architectural reviews. The defensive perimeter of the repository concludes with .env.example, .gitignore, and .dockerignore. The .env.example file is an executable security contract that defines mandatory environment keys, credential origins, and safe local defaults without exposing live secrets. Behind it, .gitignore protects against accidental secret leakage into source control—where committing a credential requires immediate rotation and history rewriting with git-filter-repo, since git packfiles retain deleted files indefinitely. Alongside it, .dockerignore prevents build daemons from leaking local environment files into distributable image layers, backed by pre-commit scanners like TruffleHog or Gitleaks to intercept credentials before they enter git history. --- The AI Code Generation Paradox This discipline matters more in 2026 than it ever has — because the next reader of your repository root is not always human. In 2026, the marginal cost of writing code has effectively dropped to zero. Any developer or autonomous agent can invoke a modern language model and generate five hundred lines of syntactically flawless implementation in seconds. Teams celebrate the illusion of velocity because tickets move across sprint boards faster than ever before. Yet software engineering has never been governed by the speed of syntax generation; it has always been governed by the economics of maintenance. A comprehensive empirical investigation, Coding on Copilot: 2023 Data Shows Downward Pressure on Code Quality by GitClear, analyzed 153 million lines of code written between 2020 and 2023. Their research revealed that code churn projected to double compared to pre-AI baselines. Simultaneously, the proportion of copy-pasted code rose dramatically, while deliberate refactoring, code movement, and deduplication plummeted. The mechanism driving this trend is structural. Large language models operate within finite context windows and optimize for local completion rather than global coherence. When an AI assistant or autonomous coding agent is asked to implement a feature in a sprawling repository with ambiguous directory boundaries, it suffers from context poisoning and prompt pollution: scanning the repository root ingests stale handoff documents and conflicting configuration artifacts into the agent's working memory, which the model treats as authoritative ground truth. Rather than constructing a unified domain abstraction, the agent takes the path of least resistance: it duplicates utility helpers, introduces direct cross-module couplings, or dumps ephemeral scripts into the root folder. Without rigid physical boundaries and explicit architectural constraints, AI coding assistants do not eliminate technical debt; they accelerate repository decay at ten times human speed. In the AI era, architecture is no longer merely a human convention. It is the structural fence that prevents automated agents from drowning a production system in unmaintainable sludge. --- The Morning After the Folder Reorganization Now assume your team executed this root discipline flawlessly. You cleaned up root sprawl, established immutable migrations, standardized workstation automation with just, decoupled deployment manifests per ArgoCD guidelines for a separate config repo, and created crisp domain directories inside src/: /auth/, /transactions/, /ledger/, and /webhooks/. The pull request merged, and the team celebrated. Then, three weeks later, a critical merchant integration deadline loomed at 4:30 PM on a Thursday. A senior engineer needed to verify whether a customer had an active KYC flag before allowing a webhook retry. The KYC verification lived in /auth/. The webhook retry logic lived in /webhooks/. Under deadline pressure, the engineer did not design an asynchronous domain event or an anti-corruption interface. They simply typed: import { verifyCustomerKYC } from '../auth/service'; The pull request passed code review because the reviewer was rushing to cut the sprint release. It passed continuous integration because the TypeScript compiler resolved the path without issue. With a single keystroke, the architectural boundary was punctured. Six months later, /auth/ imported /transactions/, /transactions/ imported /ledger/, /ledger/ imported /webhooks/, and /webhooks/ imported /auth/. On disk, the repository appeared neatly partitioned into four domain folders. In memory, the application had collapsed into a tangled, circular distributed hairball. !Diagram 10: Week 1 Intended Decoupling vs. Month 6 Tangled Hairball This represents the central operational dilemma of software architecture: drawing boundaries on a whiteboard is trivial, but keeping them from eroding under sprint pressure is where engineering actually occurs. --- The Running Case Study: The Entangled Fintech Engine To observe how boundaries erode and how to restore them, consider a production fintech payment engine. Financial systems operate under strict regulatory and mathematical constraints, making them ideal for studying boundary decay. fintech-engine/ └── src/ ├── auth/ │ ├── token.ts # Directly queries transaction tables for fraud flags │ └── user.ts ├── transactions/ │ ├── processor.ts # Imports ledger directly; bypasses immutability invariants │ └── gateway.ts # Talks to Stripe/Adyen ├── ledger/ │ ├── entry.ts # Imports webhook dispatcher inside atomic transactions │ └── account.ts ├── webhooks/ │ ├── dispatcher.ts # Synchronously invoked by ledger; network timeouts crash payments │ └── payload.ts └── shared/ └── db.ts # Shared global connection pool exposing raw SQL execution !Diagram 11: Entangled Dependencies and Shared Database Pool in the Fintech Engine This system must protect an inviolable architectural invariant: the double-entry balance invariant. Across all ledger accounts, the sum of all debits must strictly equal the sum of all credits at all times. No external service—whether an authentication handler, an external payment gateway adaptor, or a webhook dispatcher—may ever directly write to, bypass, or mutate ledger balance records. In the unsegregated codebase, that invariant is compromised daily. Novice engineering teams routinely treat account balances as mutable state, issuing destructive updates like UPDATE accounts SET balance = balance + 100. In high-throughput environments, this design pattern guarantees row lock contention, deadlocks, and silent reconciliation discrepancies. In contrast, industry benchmark financial platforms—such as Stripe's immutable ledger infrastructure handling five billion events per day—treat money movement strictly as an append-only event stream of balanced debit and credit entries. Balances are derived projections rather than mutable database columns, completely decoupling the financial source of truth from transient application state. The first time I saw this pattern in production, the circular dependency wasn't obvious from the code — it was obvious from the deployment. Changing the ledger required redeploying the auth service, which required redeploying the webhook dispatcher. Nobody could explain why anymore. In our entangled fintech engine, when a payment arrives, processor.ts opens a database transaction, calls gateway.ts to charge a credit card, directly executes an SQL update against the ledger accounts table, and immediately invokes dispatcher.ts to send a webhook to the merchant. If the merchant's webhook endpoint times out or returns a 500 error, the entire database transaction rolls back, undoing the ledger entry even though the customer's credit card was already charged. The business logic of the ledger was held hostage by an unreliable external network call because no architectural boundary isolated their failure domains. --- The Mathematics of Boundaries: Coupling Metrics That End Subjective Debates Architectural reviews frequently devolve into subjective debates where senior engineers argue personal preferences regarding clean code. To eliminate subjectivity, architects rely on the package coupling metrics formalized by Robert C. Martin. !Diagram 12: Afferent Coupling (Ca) vs. Efferent Coupling (Ce) in the Fintech Engine Afferent coupling, denoted as $C_a$, measures the number of classes or modules outside a package that depend upon classes inside it. A high $C_a$ indicates high responsibility: many parts of the application rely on this module, meaning any breaking changes to its public interface will reverberate across the system. Efferent coupling, denoted as $C_e$, measures the number of classes outside a package that classes inside this package depend upon. A high $C_e$ indicates high dependency: the module relies on numerous external abstractions and is vulnerable to breaking whenever its dependencies change. From these two metrics, Robert C. Martin's instability metric detailed in Clean Architecture derives the Instability Metric, denoted as $I$: $$I = \frac{C_e}{C_a + C_e}$$ The Instability metric ranges from zero to one. When $I = 0$, the module is maximally stable: it has zero outgoing dependencies ($C_e = 0$) and many incoming dependencies ($C_a > 0$), making it difficult and expensive to change because many systems rely on it. When $I = 1$, the module is maximally unstable: it has zero incoming dependencies ($C_a = 0$) and multiple outgoing dependencies ($C_e > 0$), making it volatile, easy to change, and dependent on external stability. Applying this formula to our fintech engine reveals exactly where boundaries must be drawn. The ledger/core domain should be designed with $I \approx 0$: nothing in the ledger should depend on authentication, payment gateways, or webhooks. Conversely, webhooks/dispatcher should operate with $I \approx 1$: it exists at the volatile edge of the system, consuming domain events and orchestrating outbound HTTP requests. This leads directly to the Stable Dependencies Principle (SDP): depend in the direction of stability. A module should only depend on modules that are more stable than itself. If a stable module like ledger with $I = 0.1$ imports an unstable module like webhooks with $I = 0.9$, the instability of the webhook package infects the ledger, destroying its stability and introducing unpredictable regression cascades. !Diagram 13: Robert C. Martin's Instability vs. Abstractness Health Map and The Main Sequence When a module is maximally stable ($I = 0$), it must also be abstract; otherwise, it becomes rigid and unmaintainable. Conversely, modules that are highly concrete should remain unstable ($I = 1$), allowing them to be modified rapidly without breaking external consumers. Calculating the distance from the Main Sequence, defined as $D = |A + I - 1|$ where $A$ represents abstractness, provides an objective mathematical index of architectural health that eliminates opinion from pull request reviews. --- Making Boundaries Irreversible: Language-Level and Tooling Enforcement Conventions documented in internal wikis or discussed during architecture offsites will always collapse under the pressure of production deadlines. If the compiler, the language runtime, or the continuous integration pipeline allows an illegal cross-boundary import, an engineer working under sprint duress will eventually merge it. Sustainable architecture requires mechanical enforcement. A landmark demonstration of mechanical boundary enforcement occurred at Shopify between 2019 and 2022. Shopify operated a massive Ruby on Rails monolith containing over 2.8 million lines of code. Over a decade of hypergrowth, coupling between disparate parts of the monolith became so severe that test suites took hours to run, boot times crippled developer workstations, and unexpected regressions occurred continuously. Instead of paying the enormous operational tax of splitting into dozens of microservices, Shopify built and open-sourced Packwerk in September 2020. Packwerk runs static analysis on Ruby abstract syntax trees during CI builds, enforcing two boundaries separately: package privacy (preventing external packages from referencing internal constants directly) and explicit dependency declarations (forbidding undeclared inter-package couplings). In their honest retrospective, Shopify acknowledged that Packwerk is "a sharp knife"—at points they even evaluated removing it due to developer friction and ongoing maintenance overhead. Yet the structural value was undeniable: > "Packwerk has provided value in holding the line against new dependencies at the base layer of our application." By turning module boundaries into automated build gates, Shopify significantly reduced unexpected regressions, cut test suite times, and maintained the operational simplicity of a single deployable application — without the coordination overhead of splitting into dozens of microservices. Modern ecosystems provide distinct mechanisms to make boundaries irreversible: !Diagram 14: The Mechanical Boundary Enforcement Hierarchy — From Compiler Gates to Linters In the Go toolchain, internal/ packages enforce privacy directly through the compiler, terminating builds if external packages attempt unauthorized imports. In Rust, pub(crate) and hierarchical module scoping provide compiler-level guarantees that private domain logic cannot be accessed beyond designated crate or module boundaries. In the Node.js and TypeScript ecosystem, modern packages utilize the exports map in package.json alongside subpath imports to declare public entry points while marking internal implementations unresolvable to external consumers. Furthermore, monorepos running Nx, Turborepo, or TypeScript Project References use tools like eslint-plugin-boundaries to enforce boundary rules in CI, failing builds if presentation layers import persistence databases directly. In the Java and Kotlin ecosystems, architects achieve equivalent mechanical enforcement using ArchUnit. ArchUnit allows engineers to write unit tests that inspect compiled Java bytecode, verifying architectural rules in compiled bytecode as automated assertions: @Test public void ledgerShouldNotDependOnWebhooks() { noClasses() .that().resideInAPackage("..ledger..") .should().dependOnClassesThat().resideInAPackage("..webhooks..") .check(importedClasses); } If a developer introduces an illegal import between ledger and webhooks, the build breaks during standard unit testing, preventing the violation from ever reaching a shared branch. Stripe implemented a parallel pattern across their monolithic Ruby codebases, developing the Sorbet static type checker to enforce strict directional dependency graphs and prevent payment processing logic from coupling to customer billing models. These automated boundary checks represent concrete implementations of Architectural Fitness Functions, an engineering discipline formalized by Neal Ford, Rebecca Parsons, and Patrick Kua in Building Evolutionary Architectures. Just as unit test suites continuously verify that business calculations produce correct numerical output, architectural fitness functions provide continuous, automated verification that structural invariants—such as package instability, directional dependencies, and blast-radius isolation—do not degrade under deadline pressure or unvetted AI-generated PR volume. --- The Architecture of Intent Before an engineer ever traces an execution thread through a database transaction or measures the throughput of an asynchronous message queue, the architecture of the system has already communicated its intent. The macroscopic geography of the repository speaks through its root contracts: its immutable migration ledgers, its isolated infrastructure blast radii, its automated task runners, its regulatory code ownership, and its defensive pre-commit firewalls. When you step inside src/, that same architectural discipline transforms into boundary enforcement. By replacing subjective debates with mathematical coupling metrics, identifying core domain invariants like the double-entry balance rule, and backing those boundaries with compiler and CI gates, teams insulate their systems against sprint fatigue, deadline shortcuts, and unchecked AI-generated code sprawl. The boundary is drawn. The enforcement is in place. But boundaries are not static — they are stress-tested every time the team grows. In Part 3, we map the universal root of the fintech engine — every folder, every governance file, every security contract — and the precise moment each one became necessary. Before we watch the system grow, we need to understand exactly what we built.