HN user

beny23

577 karma

Pragmatic software engineer with lots of hats

Posts53
Comments66
View on HN
research.jfrog.com 5mo ago

Potentially Critical RCE Vulnerability in OpenSSL

beny23
10pts1
documentation.solarwinds.com 5mo ago

SolarWinds Web Help Desk Unauthenticated Remote Code Execution Vulnerability

beny23
2pts0
www.cyera.com 6mo ago

Ni8mare – Unauthenticated Remote Code Execution in N8n

beny23
4pts0
beny23.github.io 8mo ago

Vibe Hacking a Padding Oracle

beny23
2pts0
beny23.github.io 9mo ago

Make it so: GenAI, OpenAPI and ZAP

beny23
1pts0
beny23.github.io 1y ago

AI Is the Enshittification of Recruitment

beny23
10pts0
beny23.github.io 2y ago

XZ backdoor is not the end of open source

beny23
1pts0
beny23.github.io 2y ago

Resisting Compliance Is Futile

beny23
1pts0
portswigger.net 2y ago

Web LLM Attacks

beny23
1pts0
beny23.github.io 2y ago

AI-Dvent of Code 2023

beny23
3pts0
beny23.github.io 2y ago

AppSec Loves Agile

beny23
1pts0
www.bbc.co.uk 2y ago

Rogue Russian pilot tried to shoot down RAF aircraft in 2022

beny23
4pts0
beny23.github.io 3y ago

Functional Programming in MongoDB

beny23
2pts0
beny23.github.io 3y ago

ApocalypsAI: Skynet Not Needed

beny23
1pts0
beny23.github.io 3y ago

Best engineers should look after the worst systems

beny23
3pts0
beny23.github.io 3y ago

The Case Against Automatic Dependency Updates

beny23
2pts0
beny23.github.io 3y ago

Harvesting Logs for Fun and Profit

beny23
1pts0
beny23.github.io 3y ago

Why AppSec Fails

beny23
1pts0
beny23.github.io 3y ago

Precision Munitions for Denial of Service

beny23
1pts0
jonayre.uk 3y ago

The legend of the ten-times developer

beny23
2pts3
www.equalexperts.com 3y ago

Scaling agile without losing agility

beny23
2pts0
beny23.github.io 3y ago

The agile power of saying no

beny23
2pts0
beny23.github.io 3y ago

What’s the biggest challenge faced by the software product engineering today?

beny23
1pts0
beny23.github.io 3y ago

Less is more agile

beny23
282pts173
beny23.github.io 3y ago

A mission statement that makes sense

beny23
1pts0
twitter.com 3y ago

“Amazing” Blockchain Ideas

beny23
4pts0
beny23.github.io 4y ago

Curating Dependency Vulnerabilities

beny23
2pts0
jfrog.com 4y ago

Denial of Service Vulnerability in Envoy Proxy – CVE-2022-29225

beny23
1pts1
github.com 4y ago

GitHub: Head no longer resolves to the main branch?

beny23
3pts1
web3isgoinggreat.com 4y ago

Binance adds a branded hashtag to Twitter that closely resembles a swastika

beny23
9pts4

Really liked Jon talking about the importance of experience in development. I just wanted to add that it’s also important to consider experience on the system. Even the most talented developers will need time to find their feet if they’ve only worked with a system for a few months.

So don’t treat developers as replaceable resources! If you fire an experienced team because you found some cheaper bums on seats elsewhere, you’ll usually pay the price!

Of course nobody would exploit this by submitting a PR that just deleted the failing test…

Adding money to the mix or automating rewards is asking for abuse and would decrease the quality of the software.

Also, which open source project is awash with money that could afford to pay out?

I think this (monetisation/crypto) is a solution looking for a problem and open source isn’t it…

Less is more agile 4 years ago

The problem is that all too often do customers think they know what they want but actually have NFC what they need.

Unless there is a constructive dialogue between the people who build it and the people that want it, it will end disastrously. Just think of all the failed white elephant projects that get “negotiated” on the golf course.

Until there’s an acceptance that being agile isn’t just something developers do but has to be adopted by the whole org, it’s not going to work. I know it sounds a bit dreamy but I’ve worked in big orgs that did agile rather well, so it is possible…

Less is more agile 4 years ago

I used to work in banks where you had teams of architects create high level design (HLD) docs that get turned over to the design team to produce low level designs (LLD) that the get turned over to developers how are meant to write the code, then to be turned over to the testing team. With massive handover meetings at every stage and forests of paper for milestone documentation that had to be signed off.

Never had my soul be destroyed as completely and I seen such a massive waste of time and money.

Less is more agile 4 years ago

Sounds to me that the artificial crunch is the problem. And if you have the capability to deploy quickly, I don’t see any value in sprints they tend to artificially delay deployments, reviews or retrospectives. If something needs talking about, don’t wait for a ceremony in a week and a half when everyone has forgotten about it.

I’ve been part of teams working this way without sprints and artificial crunch on mature and large scale services, so it really isn’t a MVP/startup only deal…

Less is more agile 4 years ago

I’m not a fan of ceremonies/rituals and always have to laugh when looking up the dictionary definition of ceremony/ritual which implies something that gets because “we’ve always done it” but is actually pointless. Pretty much on the nose. If something is useless, then change it!

Less is more agile 4 years ago

The worst thing about Agile is the commercialisation that came with agile training coaches and certifications. It always boggles my mind when realising how many people think “agile” means sprints, backlog grooming, Fibonacci sizing or planning poker and not what’s in the manifesto.

When you take it back to its roots and cut out all the Scrum or SAFe nonsense and adapt it to your team it can really work.

Note, I’m not saying estimates are bad per se and can imagine teams for whom it does work, but it would have to be something that the team is happy with not an impose-from-above methodology…

Less is more agile 4 years ago

I think the main thing about agile is a plan-do-study-act cycle than can be adapted to anything even project management. The trick is not to think I can just adopt a process and will then be agile. It always has to be adapted to context and what works for you.

As to CI/CD pipelines: I think a centralised devops team that blocks everyone is as much an anti pattern as a wild-west approach where 3 teams operate 4 different CI/CD tech stacks. There is much to be said about building a platform (when the size of the operation is big enough to warrant it) and using golden paths or paved roads.

From a security point of view it is absolutely heartwarming to see such an open, no-nonsense advice by NCSC. Security responses should NOT be running round like headless chickens driven by fear and the latest blogpost with cool logo and "the world is going to end" advice from security snake oil merchants. And I'm still laughing at "Adequate Pernicious Toerag".

Oh god no

relax, we’ll use a low-energy proof of stake chain

But someone will need to put up stakes. How long before you can bid to buy “is-odd” and everyone wanting to use it paying you a small fee. Crypto style libertarianism and open source freedom are not compatible….

Hello, author here. I do think the open source licence is framed to be non-discriminatory and I think that’s not a bad thing. Discrimination lends itself to politicisation and in turn division. And I think an ecosystem where we have lots of division is not good. What would happen if two interdependent projects suddenly had conflicting political requirements?

While I completely abhor the invasion, I can't help but feeling that the licence (and equally important) accompanying code change - https://github.com/terraform-aws-modules/terraform-aws-eks/b... - feels like a weaponisation of open source, and I think this is a dangerous thing to do. I do think that with change of "additional terms & conditions" to "additional information", it still feels an ethically dangerous place to be.

I would not be happy if a library codifies political statements. What could be next? Conditions that state you agree to vote for/against Trump, that you disagree with homosexuality or are against transphobia. Note, I'm not accusing anyone of having those views neither am I commenting on them, they merely serve as an example of the dangers of discriminating.

Dependencies and supply chain attacks are the big thing - and while dependency scanning and pinning are an important component, but I don't think it is possible to use open source libs at scale without a certain amount of trust. I work on a platform where there are hundreds of teams and thousands of microservices. I'm now trying to think how we can assess the risk of thousands of dependencies and millions of lines of code. Without trust, the only way that's possible is to fork all libs, prevent open source and generally kill off any agility and velocity. My problem is that this weaponisation is killing off trust. It's not about sitting on the fence or taking sides in a war. It's about what open source has achieved over the last 30 years and I think that's now more at risk than before…

Don’t know about google but in AWS the equivalent rule only looks at the first 8k of the body. There’s a separate rule for the header and another rule to block requests with header size exceeding n KB. If you allowed large headers then you could prevent the header rules too, but IIRC by default it doesn’t. Besides most web infrastructure would barf at huge headers…