Jerusalem, Israel
2017
  |  By Shauli Rozen
The blast radius of a prompt injection against your coding assistant was set weeks ago, by whoever built the dev environment image. Same assistant, same model, same injected sentence: on a laptop it collects every repository, SSH key and cloud login the developer holds; on a provisioned dev box it collects an organization token plus whatever the image left behind; on a CI runner it collects a deployment credential and a network path to production. Three environments, three incidents, one payload.
  |  By Yossi Ben Naim
Every action in your agent-incident runbook operates on the agent. The payload of a RAG prompt injection sits in the index. You can kill the pod, rotate the credential and revoke the session, and each of those stops this workload from doing that thing again. None of them touch the chunk that caused it.
  |  By Ben Hirschberg
Tool output is untrusted because your own systems produce it. That is the part of the OWASP guidance that never makes it into a deployment. The label goes on web pages and email bodies, where an outsider obviously wrote the text. It never goes on the ticket store, the CRM, or the repo, because those are yours. The attacker does not care whose system it is. He cares which field takes free text: the ticket body, the opportunity note, the PR description.
  |  By Ben Hirschberg
Your coding agents run overnight on cloud dev boxes, with auto-approve on and an organization token in the environment, and the only thing standing between a public repository and that token is whatever the repository’s README tells the agent to do.
  |  By Shauli Rozen
Prompt injection is three things happening at once. The definition written in 2022 described a model that followed an instruction hidden in the text it was asked to translate. The definition needed in 2026 describes an agent that read a support ticket and then queried a customer table it had never touched, using a service account nobody had revoked. Those are the same attack.
  |  By Yossi Ben Naim
Prompt injection has not changed since 2022. What the model can do has. The instruction that hijacked a translation bot four years ago and the one that opened a homeowner’s windows last year are the same request: do something you are already allowed to do. The first system could only talk. The second could operate devices. Same sentence, different consequence. Here are ten real attacks, in order, and for each one the thing the system was allowed to do that made it work.
  |  By Ben Hirschberg
Prompt injection has a CWE, and the two incidents everyone cites were not filed under it. That is not a clerical detail. A CWE ID is a claim about root cause, and every entry carries a mitigation table that follows from the root cause it names. When a record says CWE-1427, it is saying the product failed to neutralise input before building a prompt, and it is implying that neutralising the input is the fix.
  |  By Yossi Ben Naim
A prompt injection test suite can only report on the payloads it contains. That sentence is the whole problem with the number most teams have. Somewhere in a ticket there is a scan result: a scanner threw several hundred probes at the endpoint and a percentage got through. The percentage is real.
  |  By Ben Hirschberg
Here is a scene every security team knows. A reverse shell opens a connection to an external address, pulls a service-account token, and starts moving against your cloud identity. Two rows below it on the same dashboard sits a payload that hit a front-end container and never executed. Both are tagged high severity. Both are competing for the same analyst’s attention at the same moment.
  |  By Shauli Rozen
Every AI-SPM tool runs posture and detection with a single arrow: runtime evidence flowing back to rank posture findings. The load-bearing direction runs the opposite way, and almost nothing runs it — posture flowing forward to tell the detection layer what an attack even looks like.
  |  By ITProTV
With the short week for the Thanksgiving holiday in the US, the Technado team decided to have a little fun by looking back at some of the dumbest tech headlines from 2019. Romanian witches online, flat-earthers, and fake food for virtual dogs - what a time to be alive. Then, Shauli Rozen joined all the way from Israel to talk about a zero-trust environment in DevOps. IT skills & certification training that’s effective & engaging. Binge-worthy learning for IT teams & individuals with 4000+ hours of on-demand video courses led by top-rated trainers. New content added daily.

ARMO closes the gap between development and security, giving development, DevOps, and DevSecOps the flexibility and ease to ensure high grade security and data protection no matter the environment – cloud native, hybrid, or legacy.

ARMO is driving a paradigm shift in the way companies protect their cloud native and hybrid environments. We help companies move from a “close-the-hole-in-the-bucket” model, installing firewalls, defining access control lists, etc. to a streamlined DevOps- and DevSecOps led model in which environments are deployed with inherent zero-trust.

Security at the Speed of DevOps:

  • Runtime workload identity and protection: Identifies workloads based on application code analysis, creating cryptographic signatures based on Code DNA to prevent unauthorized code from running in the environment to access and exfiltrate protected data. The patent-pending technology signs and validates workloads in runtime throughout the entire workload lifecycle.
  • Transparent data encryption: Transparent data encryption – keyless encryption – robustly and uniformly encrypts and protects files, objects, and properties, requiring no application changes, service downtime, or impact on functionality. It eases the adoption of encryption by removing the complexity of key management and providing an out-of-the-box solution for key protection in use, key rotations, and disaster recover procedures.
  • Identity-based communication tunneling: Transparent communication tunneling ensures only authorized and validated applications and services can communicate. Even if attackers steal valid access credentials, they are useless because the malicious code will be unsigned. Create API access polices to build identity-based policies and enforce correct workload behaviors.
  • Application-specific secret protection: Application-specific protection of secrets ensures cryptographic binding between continuously validated specific workload identities and their confidential data, delivering complete protection against access by unauthorized applications.
  • Visibility & compliance: Visibility and compliance monitoring provide granular details about workloads and running environments, including individual processes, file names and locations, open listening ports, actual connections, mapped volumes, opened files, process privilege levels, connections to external services, and more. Alerts can be used for continuous compliance verification.

Bringing Together Run-Time Workload And Data Protection To Seamlessly Establish Identity Based, Zero-Trust Service-To-Service Control Planes.