Holy Hash!

Security is quality under attack. Hard-won lessons in software security, from someone who built the programs and wrote the standards.

29 March

On the use of LLM (“AI”) in security decisions

What will happen if we keep using Large Language Models as the basis of decisions, especially in a field like security? Would taking the statistically average decision from this moment on, at every step, lead to a decay of decision correctness over time, or would it stay stable?

The question sits at the intersection of decision theory, statistics, and ergodicity. The short answer is: decay, almost inevitably, and for several reinforcing reasons.

Non-stationarity is the dominant force. The world drifts, markets shift, relationships evolve, technology reshapes the landscape under your feet. The historical average decision was optimal, or at least adequate, for the distribution of situations as they existed at the time of observation. The moment you freeze your policy to “always take the average,” you anchor yourself to a past that is already receding. The longer you run on that fixed average, the more misaligned it becomes with the current environment. In security, where the adversary actively works to invalidate your assumptions, this misalignment accumulates faster than in most other domains.

Averaging destroys context-sensitivity, and this is where the damage becomes structural even without environmental drift. Good decisions are typically conditional: you do X when you observe A, and Y when you observe B. Collapse all of those into a single average and you lose the branching logic that made each individual decision correct in its context. Consider the case where your two correct responses are “accelerate” and “brake,” the average of those two is “do nothing,” which is the worst option in both situations. This holds true even in a perfectly stationary environment, because the problem is not that the average is outdated but that it never captured the decision structure to begin with.

Non-linear payoffs compound the problem further. By Jensen’s inequality, when the payoff function is concave or convex, the payoff of the average decision is not equal to the average payoff of the individual decisions. In many real domains, finance, health, security, engineering, the payoff functions are sharply non-linear, small deviations from the correct call carry disproportionate costs. The average smooths away the precision you need most at exactly the points where the stakes are highest.

The absence of a feedback loop removes the last safety net. A living decision-maker adapts: they observe a bad outcome, update their model, adjust the next decision. A frozen average policy has no such mechanism. Errors accumulate without correction, and in path-dependent systems, where today’s outcome constrains tomorrow’s available options, those errors compound. You do not merely fall behind, you fall behind in a way that makes recovery progressively harder.

There is one theoretical exception: a hypothetical environment that is perfectly stationary, where decisions are context-independent, payoffs are linear, and there is no path-dependence. In that narrow case, the sample mean would converge to the true optimum and remain stable. That describes almost no real decision domain, and it certainly does not describe security, where the entire game is played on shifting ground.

The decay, then, is not a risk to be mitigated. It is a structural certainty, the inevitable cost of substituting a static summary statistic for an adaptive process. The statistical significance of your historical sample gives you a precise estimate of what was correct before, but precision about the past does not protect you from drift in the present.

30 November

AI Software Design Security and Language Choice

Or, rather, the quality of the Artificial Intelligence (AI) generated software in general but it goes for security as well, naturally, since security and quality are but the two sides of the same coin. Software engineers happily embraced the wonderful possibility of being able to program in a natural language – describing the task to an agent that uses a Large Language Model (LLM) to produce the actual code. The question I want to look into today is the choice of the programming language for such endeavours.

Interestingly, when you let the LLM code for you, you should not really care all that much in what programming language it will actually produce the code. You program, that is, you explain the tasks, in English (or whatever other language you prefer) and the LLM will produce the code that should match the expected result. Especially when you are really using the proper design techniques and things like Test Driven Development, you should get the correct result if you do everything right.

It would seem then that the choice of the language is mostly cosmetic and a matter of personal preference, wouldn’t it? Or would it?

Consider the fact that the models have to be trained on existing material to actually perform their work. And the bigger and better the training base is, the better will be the result. You are sort of getting slightly below average of all the code that was produced before and suits your task. So the better the average is – the better will be the result.

So, then, we have to pose the question: if the LLM are getting trained on the existing code base, then what language should we choose? And the answer should be obvious: of course, we should pick a language with the biggest and most stable code base to get the best results. Preferably, a language that was used many times over to perform tasks similar to what we are up to. We want to use a language that has been used for a long time, so that all its corner cases and fine points are well-known, used extensively and described in as much detail as possible as well.

Here are the top 10 languages by their estimated public knowledge base size courtesy of LLM.

Rank Language Est. Public Code
Lines Of Code
Est. Public KB Size Years in Use Stability
1 JavaScript ~50 billion LOC 100% (baseline) 30 years Medium
2 Python ~40 billion LOC ~90% 34 years High
3 Java ~35 billion LOC ~85% 30 years High
4 C/C++ ~25 billion LOC ~70% 53/42 years Very High
5 PHP ~15 billion LOC ~55% 30 years Medium-High
6 C# ~12 billion LOC ~50% 24 years High
7 TypeScript ~8 billion LOC ~35% 13 years Medium
8 Ruby ~5 billion LOC ~25% 30 years High
9 Go ~4 billion LOC ~20% 16 years Very High
10 Rust ~3 billion LOC ~15% 15 years High
  • Public KB includes: open-source code, package repositories, documentation, forums, books
  • COBOL (250-800B total LOC) excluded: >99% hidden in proprietary banking/government systems
  • Fortran, VBA, SQL excluded: majority locked in corporate/classified systems
  • Stability: Very High = rare breaking changes; Medium = frequent ecosystem evolution

Suddenly, it would appear that writing code in more modern language is not a good idea when you use agentic development, right? You can clearly see that there are several languages with 30 or more years of history, stable and with a huge knowledge base to back them up. Those languages should be preferred in the design assisted by LLM and chosen as the main language for the systems completely written by LLMs.

It’s a pity COBOL is mostly used for closed proprietary systems. There is now over 800 billion lines of COBOL in daily use on production systems according to a recent survey. Imagine if that knowledge base could be used for training LLMs. We could rewrite everything in COBOL. Or imagine the power of LLM programming in C, were you able to use the 100-200 billion LOC of C programs hidden in corporate infrastructure and billions of embedded devices. Even Fortran, with its estimated corporate presence of 50 billion lines of code would be pretty awesome. This is mind blowing.

Well, we have to choose from what’s available to us and now you know what the best choices are.

13 March

CAST workshop on development security

We are holding our yearly security conference in Darmstadt on the 22nd of March – that’s next week – together with our partners from Fraunhofer SIT and CAST. This time, the focus subject will be DevOps and cloud technologies, including both operations and development preparation for the security in the cloud. The speakers are prepared to talk about a range of things from threat modeling and management down to massive tests, so I expect it will be rather interesting. We will also have a couple of presentations from companies talking about how they do things in their own cloud software in practice, so it will not be all theory either.

The conference is as usual mixed in German and English, we may ask the presenters to speak English only when we have people who do not speak German in the audience, so let us know on site. All details of the conference are here: https://www.cast-forum.de/workshops/programm/244

Come over to Darmstadt, join our conference, you will be very welcome!

19 January

A company with an SQL injection name

Finally, someone registered a company that is an SQL injection attack. We saw the license plates on cars doctored to execute SQL injection attacks but this is the first time, I think, that an attempt to crash all business SQL databases in a country is made.

The company name is: ; DROP TABLE “COMPANIES”;– LTD

The registration record: https://beta.companieshouse.gov.uk/company/10542519

XKCD cartoon “Exploits of a mom”

17 November

Don’t patch it, it’s fine?

I wrote back in 2013 about my shock at discovering that the companies are now publicly calling to stop the investment in security and avoid fixing security bugs in my article Brainwashing in security. There, we witnessed the head of Adobe security, Brad Arkin, tell us that the companies should not be wasting their precious resources on “fixing every little bug”, agreeing to the comment made by another participant, John Viega from SilverSky, that:

“For most companies it’s going to be far cheaper and serve their customers a lot better if they don’t do anything [about security bugs] until something happens.”

All right, fast forward three years and Adobe becomes a showcase. Here is what Google senior security engineer Darren Bilby, speaking at the Kiwicon, has to tell us about the security of the contemporary software:

“We are giving people systems that are not safe for the internet and we are blaming the user,” Bilby says.

He illustrated his point by referring to the 314 remote code execution holes disclosed in Adobe Flash last year alone, saying the strategy to patch those holes is like a car yard which sells vehicles that catch on fire every other week.

The security strategy at Adobe is clearly paying its dividends. Way to go, Adobe, way to go…

26 May

Data breach at LinkedIn

linkedin-default-shareApparently, there was a serious data breach at LinkedIn and many customer records were stolen including “member email addresses, hashed passwords, and LinkedIn member IDs”. LinkedIn sent out a notification informing that the passwords were invalidated. What is interesting in the note is that they included a cryptic note that the break-in was “not new”. What could they mean by that?

On May 17, 2016, we became aware that data stolen from LinkedIn in 2012 was being made available online. This was not a new security breach or hack. We took immediate steps to invalidate the passwords of all LinkedIn accounts that we believed might be at risk. These were accounts created prior to the 2012 breach that had not reset their passwords since that breach.

I can take a wild guess that they passwords prior to 2012 were stored either unencrypted, without salt, or using some very weak algorithm. The security breach itself was, of  course, “new” but the only information at risk are those passwords in the database that were stored in this old-fashioned way.

So, according to my wild guess, there must be more information stolen than they tell us but LinkedIn judged that the only information that threatens themselves were those old passwords so they finally invalidated them (what they should have done back in 2012) and told us they are happy with it.Unfortunately, there is no way to know for sure.

You can make your own wild guess at what happened.

9 February

Position yourself on Security Maturity Grid

I wrote up the Security Maturity Grid the way quality management is usually presented. The grid is a simple 5 x 6 matrix that shows different stages of maturity of the company’s security management against six different security management categories (management understanding of security, problem handling, cost of security, etc). The lowest stage of maturity is called ‘Uncertainty’ – the organisation is inexperienced, security management is a low priority and reactive, etc – then as security management matures it goes through the stages of ‘Awakening’, ‘Enlightenment’, ‘Wisdom’, then the highest level, ‘Certainty’. Each point – maturity versus category – on the grid has a brief description of how that combination appears in the company.

I keep the grid on a separate page, Security Maturity Grid, so have a look and try to position yourself or your company on the grid. Then wait for the software security goons to show up :)

dilbert-software-improvement-goons-dt050912

19 January

Worst languages for software security

I was sent an article about program languages that generate most security bugs in software today. The article seemed to refer to a report by Veracode, a company I know well, to discuss what software security problems are out there in applications written in different languages. That is an excellent question and a very interesting subject for a discussion. Except that the article really failed to discuss anything, making instead misleading and incoherent statements about both old-school lnguages like C/C++ and the PHP scripting. I fear we will have to look into this problem ourselves then instead.

So, what languages are the worst when it comes to software security? Are they the old C and C++, like so many proponents of Java would like us to believe? Or are they the new and quickly developing languages with little enforcement of structure, like PHP? Let’s go to Veracode and get their report: “State of Software Security. Focus on Application Development. Supplement to Volume 6.

The report includes a very informative diagram showing what percentage of applications passes the OWASP policy for a secure application out of the box grouped by the language of the application. OWASP policy is defined as “not containing any of the security problems mentioned on the OWASP Top 10 most important vulnerabilities for web application” and OWASP is the accepted industry authority on web application security. So if they say that something is a serious vulnerability, you can be sure it is. Let’s look at the diagram:

Veracode OWASP by language 2016-01-18-01

Fully 60% of applications written in C/C++ come without those most severe software security vulnerabilities listed by OWASP. That is a very good result and a notable achievement. Next, down one and a half to two times, come the three mobile platforms. And the next actual programming language, .NET, comes out more than two times as bad! Java is 2 and a half times as bad as C/C++. The scripting languages are three times as bad.

Think about it. Applications written in Java are almost three times as likely to contain security vulnerabilities as those written in C/C++. And C/C++ is the only language that gives you a more than 50% chance of not having serious security vulnerabilities in your application.

Why is that?

The reasons are many. For one thing, Java has never delivered on its promises of security, stability and uniformity. People must struggle with issues that have been long resolved in other languages, like the idiotic memory management and garbage collection, reinventing the wheel on any more or less non-trivial piece of software. The language claims to be “easy” and “fool-proof” while letting people to compare string objects instead of strings with an equal operator unknowingly. The discrepancy between the fantasy and reality is huge in the Java world and getting worse all the time.

Still, the main reason, I think, is the quality of the developer: both the level of developer knowledge, expertise, as it were, and the sheer carelessness of the Java programmers. Where C/C++ developers are actually masters of the software development, the Java developers are most of the time just coders. That makes a difference. People learn Java in all sorts of courses or by themselves – companies constantly hire Java developers, so it makes sense to follow the market demand. Except that those people are kids with an ad-hoc knowledge of a programming language and absolutely no concept of software engineering. As opposed to that, most C/C++ people are actually engineers and they know much better what they are doing, even when they write things in a different language. But the “coders” are much cheaper than real engineers, so the companies developing in Java end up with lots of those and the software quality goes down the drain.

The difference in the quality of the software is easily apparent when you compare the diagrams for types of the issues detected mostly from the same report:

Veracode Problem Areas 2016-01-18

You can see that code quality problems are only 27% of the total number of issues detected in the case of C/C++ while for Java code the code quality issues represent the whopping 80% of total.

Think again. The code written in Java has several time worse quality than the code written in C/C++.

It is not surprising that the quality problems result in security vulnerabilities. Both quality and security go hand in hand and require discipline and knowledge on the part of developer. Where one suffers, the other inevitably does as well.

The conclusion: if you want secure software, you want C/C++. You definitely do not want Java. And even if you are stuck with Java, you still want to have C/C++ developers to write your Java code because they are more likely to write better and more secure software.

15 December

Backdoors in encryption products

padlock-security-protection-hacking-540x334After the recent terrorist attacks the governments are again pushing for more surveillance and the old debate on the necessity of the backdoors in encryption software raises its ugly head again. Leaving the surveillance question aside, let’s see, what does it mean to introduce backdoors to programs and how they can be harmful, especially when we are talking security and encryption?

Generally, a backdoor is an additional interface to a program that is not documented, its existence is kept secret and used for purposes other than the main function of the program. Quite often, a backdoor is simply a testing interface that the developers use to run special commands and perform tasks that normal users would not need to. Such testing backdoors are also often left in the production code, sometimes completely unprotected, sometimes protected with a fixed password stored in the code of the program where it is easy to find, i.e. also unprotected. Testing backdoors may or may not be useful to an attacker depending on the kind of functionality they provide.

Sometimes the backdoors are introduced with an explicit task of gaining access to the program surreptitiously. These are often very powerful tools that allow full access to all functionality of the program and sometimes add other functions that are not even available at the regular user interface. When talking about security and encryption products, such backdoors could allow unauthorized access, impersonation of other users, man-in-the-middle attacks, collection of keys, passwords and other useful information among other things.

The idea of the proponents of introducing backdoors into security and encryption software is that we could introduce such backdoors to the encryption and other tools used by general public. Then, the access to those backdoors would only be available to the police, justice department, secret services, immigration control and drug enforcement agencies… did I miss any? Maybe a few more agencies would be on the list but they are all well behaved, properly computer security trained and completely legal users. And that access would allow them to spy on the people using the tools in case those people turn out to be terrorists or something. Then the backdoors would come in really handy to collect the evidence against the bad guys and perhaps even prevent an explosion or two.

2015-07-19-image-5The problem with this reasoning is that it assumes too much. The assumptions include:

  1. The existence and the access to the backdoors will not be known to the “bad guys”. As the practice shows, the general public and the criminal society contain highly skilled people who can find those backdoors and publish (or sell) them for others to use. Throughout the computer history every single backdoor was eventually found and publicized. Why would it be different this time?
  2. The “bad guys” will actually use the software containing the backdoors. That’s a big assumption, isn’t it? If those guys are clever enough to use encryption and other security software, why would they use something suspicious? They would go for tools that are well known to contain no such loopholes, wouldn’t they?
  3. The surveillance of everyone is acceptable as long as sometimes one of the people under surveillance is correctly determined to be a criminal. This whole preceding sentence is by itself the subject of many a fiction story and movie, “Minority Report” as an example comes to mind. The book “Tactical Crime Analysis: Research and Investigation” might be a good discussion of problems of predicting crime in repeat offenders, now try applying that to first-time offenders – you get literally random results. Couple that with the potential for abuse of collected surveillance data… I don’t really even want to think about it.

So we would en up, among other things, with systems that can be abused by the very “bad guys” that we are trying to catch while they use other, trustworthy, software and the surveillance results on the general population are wide open to abuse as well. I hope this is sufficiently clear now.

Whenever you think of “backdoors”, your knee-jerk reaction should be “remove them”. Even for testing, they are too dangerous. If you introduce them in the software on purpose… pity the fool.

21 September

CAST Workshop “Secure Software Development”

7033818-3d-abbild-monster-mit-investigate-linseWe are organizing the workshop on “Secure Software Development” now for the third year in a row. As usual, the workshop is in Darmstadt and the logistics is cared for by the CAST e.V. The date for the workshop is 12 November.

This year most presentations seem to be in German, so probably it does not make much sense for non-German speaking people. But if you speak German, we have some rather interesting subjects like our experiences with vulnerability management, research into sociotechnical basis of development security and problems with developing the mobile payment infrastructure security.

The workshop is a great place for discussions and meeting various people working on security in software development. Please, come and join us on 12 November!