Patching security problems in big old organizations involves problems that go a lot beyond “looking at code and changing it”, especially if aiming for a “strong” solution like formal verification.
TL;DR: Political problems, code that makes no sense, problems that would be easy to fix even with a simple LLM that isn’t specialized on improving security.
The best public resource I know is about this is Recoding America.
Some examples iirc:
Not having a clear primary key to identify people with.
Having a website (a form) that theoretically works but doesn’t run on any browser that people actually use.
Having a security component which is supposed to catch fake submissions of forms, but is way more likely to catch real submissions (it is imo net negative).
I also learned some surprising things from working on fixing/rewriting a major bank in Israel. I can’t share such juicy stories as Recoding America publicly, but here are some that I can:
“written in kobol” is maybe ~1% of the problem and imo not an interesting pain point to focus on
Many systems are microservices (much harder to define the expected functionality of an async system)
Different parts of the bank are written using different technologies
An example problem you’d find in the code is “representing amounts of money using javascript floats”
It’s not complicated to fix, technically
But people might say “we’re used to using floats, why change it?”
Making changes might mean they’ll have to run manual tests, so they’ll be against it
Some teams just don’t like having others touch their code, and maybe some care about their job security
Another example easy thing to fix is “use enums”
I’ve seen more than one conversations where “agreeing to use an enum” was a big political debate
Sometimes, to understand a system, I’d do a combination of “looking at the code”, “looking at the docs (word documents with the design)”, and “talking to one or more of the people in charge of the system” (sometimes different people have different parts of the picture)
[written with the hope that orgs trying to patch security problems will do well]
Patching security problems in big old organizations involves problems that go a lot beyond “looking at code and changing it”, especially if aiming for a “strong” solution like formal verification.
TL;DR: Political problems, code that makes no sense, problems that would be easy to fix even with a simple LLM that isn’t specialized on improving security.
The best public resource I know is about this is Recoding America.
Some examples iirc:
Not having a clear primary key to identify people with.
Having a website (a form) that theoretically works but doesn’t run on any browser that people actually use.
Having a security component which is supposed to catch fake submissions of forms, but is way more likely to catch real submissions (it is imo net negative).
I also learned some surprising things from working on fixing/rewriting a major bank in Israel. I can’t share such juicy stories as Recoding America publicly, but here are some that I can:
“written in kobol” is maybe ~1% of the problem and imo not an interesting pain point to focus on
Many systems are microservices (much harder to define the expected functionality of an async system)
Different parts of the bank are written using different technologies
An example problem you’d find in the code is “representing amounts of money using javascript floats”
It’s not complicated to fix, technically
But people might say “we’re used to using floats, why change it?”
Making changes might mean they’ll have to run manual tests, so they’ll be against it
Some teams just don’t like having others touch their code, and maybe some care about their job security
Another example easy thing to fix is “use enums”
I’ve seen more than one conversations where “agreeing to use an enum” was a big political debate
Sometimes, to understand a system, I’d do a combination of “looking at the code”, “looking at the docs (word documents with the design)”, and “talking to one or more of the people in charge of the system” (sometimes different people have different parts of the picture)
[written with the hope that orgs trying to patch security problems will do well]