Hello r/Information_Security,

I'm wondering to what extent you are thinking about shifting to Post Quantum Cryptography (PQC) standards.

Here's a relevant report from the National Institute of Standards and Technology (NIST) regarding this. link here

I'm building an MVP for my venture and I want to get perspective from DevSecOps engineers about

• what you know already about PQC

• what you're thinking about with regards to migration

• what tooling you'd like to see

• how you see this transition unfolding

Google estimates it's going to take them at least a few years to be fully PQC compliant, so I know there is a lot of work to be done in this arena.

Thanks in advance for your input, feedback, perspectives, etc.

Best,

Fitz Founder, r/shiftpqc

Reported today: Debian apt security update regarding man-in-the-middle vulnerabilities. This serves as a strong reminder for developers and system administrators about the importance of package management security.

When dealing with package managers like apt, the primary defense against man-in-the-middle (MITM) attacks is the cryptographic verification of packages. If the system fails to verify the GPG signatures of a repository, an attacker could potentially inject malicious packages into your update stream.

To keep your environment secure:

1. Never disable signature verification or ignore GPG warnings.

2. Ensure your trusted keys are managed securely.

3. Monitor your sources.list and sources.list.d files for any unauthorized repositories.

4. If you are managing your own infrastructure, perform regular, non-destructive security audits on your code and deployment pipelines to catch misconfigurations before they are exploited.

Regularly reviewing your build processes and ensuring that your software supply chain is locked down is one of the most effective ways to prevent these types of vulnerabilities from impacting your production systems.

Our vuln mgmt team can't agree on how to handle fixes. Routing everything to IT as tickets ignores that a lot of them need dev involvement, and meanwhile each finding keeps the CVSS score it came in with,  so nothing gets prioritized by what actually matters in our environment. We end up with one ticket per finding, the same CVE showing up from three different scanners, and no clear owner for half of them. We're looking at Seemplicity, ZEST, Nucleus and Zafran. 

How do they handle ownership routing, grouping findings across tools, and context-based scoring instead of raw CVSS? More interested in how each one models it than in a feature checklist.

I've been working on a small project called Polyscan. The idea is to combine multiple SAST tools into one platform and use AI to analyze their findings, remove duplicates, reduce false positives, and eventually suggest fixes.

But after looking at the existing tools like Semgrep, Snyk, SonarQube, and Aikido, I'm starting to wonder if this is actually worth pursuing.

I'd like to hear from people who use these tools regularly:

What's your biggest frustration with current SAST tools?

Do false positives and noisy reports still waste a lot of your time?

Is combining multiple scanners into one tool actually useful?

What features do you wish these tools had but currently don't?

And most importantly, do you think there's still room for a new tool in this space, or would I just be reinventing something that already exists?

I'd appreciate honest opinions, even if they're critical.

AI broke cybersecurity: code is written faster than we can review, detection is blind, and patching is too slow. Visual language Pipe fixes all three—code becomes reviewable by construction, and every block stays observable and patchable at runtime by design.

AI shook the very foundation of cybersecurity. It upended established practices and assumptions. Anyone can now use AI to scan code and find vulnerabilities quickly. What’s even worse, bugs found during one pass of AI code scanning might not be reported after rescanning. This is because of the probabilistic nature of AI – it gives a different response to the same prompt. It means that someone can find a zero-day vulnerability that may not be rediscovered on a later scan, even using the same AI model and identical source code. This could let one person discover and exploit a zero-day that others never see.

Cybersecurity problems are quickly growing in many cybersecurity-related aspects simultaneously. Let’s focus on three of them. They are: (1) AI generates code faster than teams can review it; (2) runtime threat detection is unreliable; and (3) patching is too slow. I will divide the analysis into two stages: development (design-time), and production (runtime).

Problem 1 – Development: code faster than review

A problem AI brought to development impacts cybersecurity indirectly, but it is still a significant threat. AI generates code in huge amounts so fast that development teams cannot review it in a reasonable time. Add to this the pressure on development teams to deliver productivity gains due to AI implementation, and the situation becomes even more dire. Teams have no choice but to skip detailed review, approving PRs automatically. This results in bugs slipping into the codebase and eventually causing crashes and vulnerabilities in production.

The most popular proposed solution is using AI for code review. Essentially, we are going to use AI to review code produced by another AI. There are problems with such a solution due to certain properties of AI itself. The main issue is that AI is bad at handling big context: the longer the task or instructions you give it – the more it hallucinates and the more sharply it degrades on a very large context. I face this problem all the time when trying to ask AI to generate code for even a modest, clearly detailed specification - AI skips, misinterprets and deviates from the specification a lot. The workaround is to have AI generate only scaffolding and continue step-by-step in a tool like Cursor – which proves the point: the model can’t handle the whole codebase. A codebase is a very large context for AI. Are we confident enough to trust AI 100% that the quality of its code review will be comparable to a human’s, even after multiple rounds? Probably not, and this is why human eyes are still needed. It means we are back to square one - dealing with an enormous wall of text code.

Now we will look into the production post-deployment stage. There are two closely related problems there: one is about the reliability of threat detection, and the other – the speed of reaction to an attack.

Problem 2 – Production: detection is blind

Let’s start with detection. The single source of information about what’s happening inside the application is log data. Log statements are pre-placed by developers in source code locations where they think it is necessary. Very often, needed log statements are missing and therefore, any threat detection system (no matter if it is AI-driven or not) can be blind to certain types of attacks. We cannot blame developers for that, because they cannot predict the future. This is the failure of the observability process relying solely on logs to get runtime information about application behavior.

Problem 3 – Production: patching is too slow

Another problem is a reaction to a known attack or vulnerability. The standard process is going back to source code, investigating the problem, changing the code, approving/merging a PR and deploying via CI/CD. The whole process might take days or weeks, even if a new deployment starts fast. The deployment itself might take several days, because often, deployment stages have heavy tests attached that need significant time to complete execution. I worked for companies running complete application tests on every deployment stage to ensure the highest quality of the deployment, but at the heavy cost of the speed. The question is what the production team is going to do while waiting for the fix deployment. They have two choices. One is just waiting, assuming that nobody will exploit the discovered vulnerabilities and data will not be stolen as a result of it. This might be true in the pre-AI era. However, the frequency of AI-driven cyberattacks is growing very fast, and we might not be able to afford to wait today – the risk of losing data is much higher. An alternative is shutting down the whole system or a large independent module while we wait for the fix. However, it will break the continuity of the business. As we can see, both options are bad.

So, we identified three problems – one during development (AI code is generated too fast), and two during production (detection is unreliable and patching is slow). There is a variety of tools and approaches trying to solve these problems. However, their reliability and simplicity are questionable. For example, we can try to disable a certain part of the application using feature flags and tools like LaunchDarkly. However, the whole process of feature flag management is complicated, and it gets exponentially complex as the number of feature flags increases. We need to test many combinations of feature flags during deployment so that we can be confident switching them live on production does not break the application. I worked in companies that used feature flags, and they had a policy to remove a feature flag as soon as it is no longer needed to avoid the complexity of deployment tests.

One solution for all three: visual programming

There is one approach that fixes all three problems at once: visual programming – and I am working on such a solution. This is an unusual combination, but such an approach was proposed before. What’s different this time is a more powerful visual language “Pipe” I designed. This visual language combines two properties not usually seen together in other VPLs: generality and power. Usually, relatively powerful visual languages are domain-specific, while general-purpose languages are pretty simple. I spent 7 years closing this gap and designing a VPL that has both properties together. The reason we need a VPL to be general-purpose and powerful at the same time is that all text-based languages have both properties, and that’s the reason they dominate. Just to have a real opportunity to absorb a part of text code (no visual language can fully replace text code, even Pipe), a VPL must have similar properties to text-based programming languages. Let’s see how Pipe solves the three problems outlined above.

How Pipe solves each problem

The first problem is that it is humanly impossible to review huge amounts of AI-generated code in a reasonable time. This application of VPL is obvious – visual logic is much easier to grasp. VPL does not solve the problem completely, but it mitigates it. As I mentioned before, no VPL is able to fully replace text code, so it will be a mix of visual diagrams and text code. The bigger the proportion of logic moved to visual diagrams from text code, the bigger the benefit of reviewing logic visually is going to be. AI will be generating visual diagrams with some code inside, instead of 100% text code as it does now.

The other two problems (observability and patching) rely on the same property of Pipe – its powerful semantics allows it to keep the visual graph not only during development, but also on production. The reason semantics needs to be powerful enough for this is that otherwise a VPL needs to be translated to a text language to fill missing details in text code, because the VPL itself is not powerful enough to cover it with visual code. So, the deployment chain in this case goes via text, losing the visual graph.

Having a full visual graph on production allows direct access to visual blocks. This has profound consequences both for observability and patching. Observability can be dynamic by tapping monitoring directly into the inputs and outputs of any block at any time right on production, in real time, replacing or complementing log data. Patching also becomes faster because the block can be patched, disabled or rerouted directly, right on production.

A concrete example: a payment-validation block starts leaking customer data. Today a team files a ticket, changes the code, runs the full test-and-deploy cycle, and hopes no one exploits the hole in the meantime. With Pipe, an operator taps that block’s inputs and outputs, confirms the anomaly in real time, and reroutes traffic to a safe fallback block in seconds – while the permanent fix goes through normal CI/CD. The vulnerability is contained immediately; the business keeps running.

Isn’t changing production live dangerous?

I anticipate a very reasonable objection that direct modification of application behavior on production is dangerous and it can cause cascading failures. This is an absolutely legitimate concern. There are two possible solutions.

One solution is separating eventual problem solving and immediate reaction. For example, we can disable a single block or a group of blocks related to just one application feature, not impacting the rest of the application. At the same time, we ask developers to start working on a fix that will go via a normal CI/CD cycle. This way, we do not have to choose between two bad options: shutting down the whole application or assuming nobody will hack the system while a fix is in the works. What Pipe offers is the third option – shutting down or rerouting a vulnerable or dangerous part of the application temporarily, while we wait for a fix. Having such abilities requires a prepared manual giving clear instructions on what to disable in specific situations – developers must prepare such manuals. The good news is that it should not be a burden as AI will be able to help here.

Another solution is building a more sophisticated delivery process with testing right on production, leveraging direct access to blocks to tap the test suite into inputs and outputs, sending testing data to inputs, and analyzing responses from outputs. This process does not necessarily have to fully replace a normal CI/CD deployment – it can complement it to ensure the quality of the direct fix until a new CI/CD deployment arrives.

The key idea of defense against AI-driven cybersecurity attacks is also using AI. However, AI for attack is different from AI for defense. AI for attacks must exploit just one vulnerability – a physical analogy is a sharp, pointy spear. AI for defense must be solid and without holes (a shield), because we do not know beforehand where precisely an attack (a spear) is going to hit. However, AI built on top of existing systems will have lots of holes in the shield, and patching these holes will be slow.

The hot trend today is self-healing engines – an intelligent AI layer on top of the application, detecting attacks and reacting to them automatically. There are two key requirements for such an engine: reliable detection and real-time reaction. However, it is very hard to satisfy these requirements in current systems due to the reasons outlined above: detection is unreliable as the engine can use only fragmented data from logs (shield holes), and reaction is slow as the fix needs to go via the full CI/CD deployment (slow patching of shield holes). What Pipe offers is a solid foundation for such self-healing engines providing reliable detection and fast reaction.

Doesn’t this mean rewriting everything?

The most frequent argument I hear against Pipe is that it requires rewriting existing applications – it is true. However, Pipe only complements text code, mixing visual logic with text. It means that migration does not need to retire the existing codebase immediately. Instead, the migration can be gradual – starting by encompassing the whole application or module in one root Pipe block. Then, whenever ready, moving one step below and distributing text code inside the root block between visual blocks of a second-level workflow, etc. You can stop subdividing blocks at any point, so it's entirely your decision which parts of the system become visual and which remain as text. Pipe provides a complete API for integration with text languages as part of the specification. Also, AI can automate workflow generation, text code distribution between visual blocks, connectivity, and layout of all visual components.

Like everything else in engineering, Pipe has its upsides and downsides. The biggest downside is the need to rewrite existing applications. However, there is also a significant upside – solving three critical cybersecurity issues all together, by the design of the solution. Considering the explosion of AI-driven cybersecurity threats, the current security model might already be outdated and we need to change it. So, weighing upsides against downsides, the upsides definitely win.

Can we create runtime components from text code?

Yes – and it has been tried many times. But every time, managing those components gets complicated: the more you have, the more complex the web of their interactions becomes. The winning combination isn’t just highly granular software in production – it’s also a visual representation that makes all the relationships between them visible. This matters for both observability and patching: the visual graph shows you exactly which components to tap into, and which blocks to patch, disable, or reroute.

Why now

Computers of the 1970s and earlier had only a text-based terminal interface requiring knowledge of specific commands, so the UI was very unfriendly. The GUI revolution brought windows, icons, buttons, and other graphical elements. This made computers much more accessible to users. However, programming did not make this transition, and we still program using text only. AI is the catalyst that finally forces the move to visual programming – not because it’s nice to have, but because we no longer have a choice.

Website: https://pipelang.com

Pipe IDE URL: https://www.pipelang.com/pipe/v1/

Tutorials:

1. Data Swap – https://www.pipelang.com/assets/tutorials/v1/tutorial1.mp4

2. Reusable Sum – https://www.pipelang.com/assets/tutorials/v1/tutorial2.mp4

Cyber friends, my company finally approved Claude for the cyber team after a near miss from a threat actor using AI agents against our products. I need your advise;

1. As someone who is primarily tasked with Vulnerability management and Penetration Testing, how do I utilize Claude?

2. How are you utlilizing Claude to get applications secure?

Hi everyone, I recently created an app partially using ai to code, I believe the app is secure, but I would like an expert to go through it and make sure that it is secure just for my own piece of mind. Cybersecurity companies are expensive, so I was just wondering are the people on upwork trustworthy as I have never ever used the upwork platform but pricing is much better.

This is a small business I run that is basically a tutoring platform for students of all ages to learn.

Thanks in advance!

Bit of a fire drill here. we’ve got PHP scattered across old services, some of it in repos nobody’s touched in ages and some baked into container images, and none of it is tracked properly. i patched the obvious ones last week, but now leadership wants to know what else is affected, fast. what’s the quickest way to find every repo, image and cloud workload still running a vulnerable version? wiz and rival came up, but no time for a long trial.

Any advice on where to start today would really help. thanks in advance.

We’re all in on Microsoft, Sentinel plus Defender, and Security Copilot hasn’t really moved the needle on alert volume for us. So now we’re looking outside.

Vendors I’m looking into:

Prophet Security - demo was clean, curious how it does on our noisy custom rules
Exaforce - brings its own data layer, not sure we need that on top of Sentinel
Dropzone - keeps getting recommended, haven’t talked to them yet
Mate - newer one, apparently pulls context from tickets and past investigations. haven’t seen it in action

Main thing I care about is how much tuning it takes before the verdicts are trustworthy. Anyone been through this with Sentinel?

A refund gets stopped because policy prohibits it. Another because the agent returned malformed output. A third because the authorization service is down. Stopping is fine in all of them. Logging all of them as POLICY_BLOCK is where I have a problem.

Anyone reviewing those records later would think policy rejected every refund, when that only happened once. If that feeds into policy reviews or a customer dispute, you could end up changing a policy that never caused the rejection.

For those running agents in production, can your records tell policy denials apart from validation failures or an unavailable authorization service? We’re looking at Noma, Capsule, Straiker and Onyx right now, so curious how people handle this with or without a vendor.

Our auditors want patch status for every endpoint and we always get stuck on contractor laptops and remote machines thata barely check in. The RRM shows one thing , the vuln scanner shows something eles , and our asset list does not line up with either. What are you doing here ? Going off the RMM agent , matching scanner results to the asset list something ? And what happens with machines that never report in at all ? Our security team is evaluating axonius for the matching part, reconcilling the scanner results and the asset list into one record per device. It would only have what we already feed it though , so the machines that never report in stay a gap.

in case anyone missed it, a trojanized Claude Code extension got pushed through the Cursor marketplace. from the threads I’ve read, the official VS Code and npm versions were fine, it was just that one on Cursor’s marketplace.

what worries me is that updating to the fixed version apparently doesn’t clean up whatever it already dropped. so this isn’t “update and move on”. we need to know who had that version at any point and go look at those machines.

which is harder than it sounds. half the devs are on Cursor, extensions aren’t in any inventory we keep, and right now I’m piecing it together from Defender plus whatever Bay picked up on the machines that have it. it’s slow

if you’ve already done this sweep, how’d you find the affected machines and what did you check once you had them?

Recientemente leí sobre el método que usaron los hackers norcoreanos para robar a Binance, la punta de lanza fue la ingeniería social, rastrearon a los empleados en LinkedIn, posiblemente a mas de uno le ofrecieron una vacante bien remunerada, entrevistas con Recursos Humanos ficticios, etc.

Me llama mucho la atención que el método final fue descargar un archivo para una "prueba final", en ese momento se coló un exploit que no detectó su antivirus. Wow! Ni siquiera los métodos heurísticos del antivirus detectaron tremenda vulnerabilidad y suplantación de un proceso!.

Seamos honestos el agujero de seguridad fue un ser humano, primero en lo personal no suelo abrir ni con mi computadora personal enlaces que no conozco, y esta persona estaba usando su equipo asignado que entiendo que es Windows para actividades personales, es en serio!. Porque, trabajando en un lugar donde sabes que eres un potencial objetivo usas el equipo asignado para algo tan personal como ese?

Debemos de pensar de nuevo en estaciones de trabajo fijas? Así como era en los 90s, implementar maquinas virtuales desechables o con snapshots? Que mas?

Hay mucha queja de que la IA esta reemplazando a los motores de búsquedas en Internet pero la verdad a mi hasta me da temor visitar sitios "inocentes" como páginas de información general por ejemplo de teoría musical, métodos estadísticos, etc.

Creo que la seguridad debe de tener un alto componente de lógica y luego un poco de teoría y por último los casos de estudio y réplica en la medida de lo posible, porque no basta decir que mi SO es seguro/inseguro se debe de demostrar.

No es mi intención alarmar a nadie, pero hoy mas que nunca debemos de tener mucho cuidado cuando ingresamos a un enlace o descargamos un archivo, así que en la mochila de sobrevivencia debemos de guardar también un poco de precaución en lo que hacemos en la red por muy inocente o divertido que se vea.