Bill Sempf

How I built my AI, Chiron

bill@pointweb.net — Fri, 27 Feb 2026 04:27:00 +0000

At the end of last year, I came to the conclusion that I had no choice but to stand up a lab at POINT that specifically was designed for me to learn about machine learning and large language models. As mentioned in my last post, I think that understanding the implicit uses and dangers of this relatively new breed of technology will be extraordinarily important going forward.

So first, hardware. I did some research and the hacker folks in my feeds were all using old hardware or Raspberry Pis just to say they could, which is cool. In fact Brent Huston at Microsolved wrote the article that started this all in a lot of ways. I am all about reusing devices, I have laptops that are 20 years old performing important functions at the Sempf Compound. For this, though, I needed a real research box, so I dropped the other shoe and got a mini PC (not this one).

Great now I have a place to put stuff. What to put where? After hemming and hawing I decided I wanted to have multiple machines running, and I wanted functional separation, because it makes my brain better. When I was in the dev space, I had a server running Windows Server and Hyper-V so that I could spin up a whole new machine that replicated the environment I was coding for It worked out well, and I wanted to emulate that with something lighter weight that wasn't a Microsoft product. So I started with Proxmox. I am not going to go into the setup and whatnot because there are FAR better guides out there than mine (I'd link but they go out of date fast) so I'll just say I have 128 gig of ram split amongst a few machines running things I want to keep separated. And if I ever run out of money I can sell the RAM and move to Cancun.

Alright, now I have a random empty virtual machine, so I started with what I know and installed Ubuntu. Your milage may vary of course. I think *nix is far superior for this kind of thing because of the file system but there are more options of course. Your distro of choice will be acceptable.

Next we will need a server to store our language models. No, we are not going to use remote services, this is something I want to be able to disconnect from the Internet and use. It is going to be designed to be a solo operator, so we need our own LLM services. Fortunately for me, there is Ollama. The good news is that installing it is just:

curl -fsSL https://ollama.com/install.sh | sh

So no complaints there. Now we have our own delivery service for an LLM, and can use the command line to go grab models from the open store. "What," you ask, "there are free models?" You bet. You won't get GPT5.3Codex (that joke is probably out of date already) but there is a lot available, and some of them are even ethically constructed so do your research. But we aren't stuck here. All Ollama does is provide the access to the models in all of the expected ways. We need a chat interface.

OpenWebUI enters the chat. This extremely generically named tool is the ChatGPT or Le Chat for our instance of Ollama. There aren't enough ways to describe how awesome this open source project is. It is large, complex, and it works. It is well documented and the core team is remarkable. Throw them some money if you can.

To focus OpenWebUI's chat, we need to give it a system prompt that will provide a personality. I have mine here, and you are welcome to steal it as a template - I stole VSCode's as a template so fair's fair. Steal and steal alike, amirite? You can do a lot with Soul files, and when I write about AI Concoles later I'll put some information up and the Claude and Mistral Soul structures, and how to try and bend the model to your needs, at least in the chat.

But anyway, with OpenWebUI we can specify a model from our Ollama instance, and then create a Workspace, which is OpenWebUI's interface for RAGs. More or less, what I have done here is given Chiron all of my books, and everything I have written, and all of the OWASP CheatSheets, the Testing Guide, and the ASVS. This has generated the POINT Application Security Intelligence.

It's not that terribly intelligent

I mean, it does exactly what I want it to do a vast majority of the time, but it will do all of the things that I am certain that you have heard the stories about. I give it 7 vulnerabilities, and ask it to build descriptions and remediation steps, and it will do three. Ta daaa! "No," I say in the chat, "there were 7, where are the other four?" "You are absolutely right, I only handled three of those! Let me do the other four."

And then it does two more. Ta daaaaa!

So there is still a way to go. That's just a small obvious example, there are subtle things too. I asked it to help with a code example for a remediation step, and while it did remediate the vulnerability, it introduced a new one. There is unquestionably more that needs to be done.

But it does something extremely well. For instance, I am clearly not going to load a client's source code into Mistral for analysis. It's a violation of the NDA I share with my clients and I am just not like that. But I can load it into Chiron for analysis because it never leaves my office. All and all a worthwhile project I recommend for everyone.

On Artificial Intelligence

bill@pointweb.net — Mon, 16 Feb 2026 04:14:00 +0000

There has been so much conversation about artificial intelligence over the last 5 years that I hesitate to write anything at all. I wanted to make my experience clear, the research I had done available, and elicit discussion. But it seems like that all anyone ever talks about on the couple of social media outlets I hang out within. And there is a lot of heavy breathing.

There is a good reason for that. Some of this is kinda life changing. I mean, none of this just popped up out of nowhere. We have been working on language models and machine learning - the two technologies at the heart of this mess - for nearly 50 years. Only in the last 7 years have we had the hardware even invented that could do the (once) theoretical large language model. Only in the last 5 have we had it in place. Only in the last twelve months have we figured out how to use it. Only in the last four or so months have there been products built that can make use of it.

Things are moving fast.

My path so far

I read Matt Schumer's article recently. He's a techbro, sure, but he is a pragmatic developer and well respected. His thoughts gave me pause.

https://shumer.dev/something-big-is-happening

He says "I know this is real because it happened to me first." I feel you bro. When OpenAI first published its API, I wrote a simple application that would accept the list of vulnerabilities from my pentesting template and write quick descriptions. It didn't work very well, so I put it up, but I thought about it.

Later, when Microsoft introduced Copilot, I used it for writing little bits of JavaScript that I couldn't remember the syntax for - I'd have to look it up, like that. It was OK at that. I asked it to build a class though, and not so much. Still, useful for fixing my shitty asynchronous JavaScript code.

Then I went to CodeMash, Cory House, yes, that Cory House, was giving a talk on using AI tools in development. I thought "OK, I'll give this a try." He was using these new vibe tools, so I installed Claude and followed along while we built an entire working, tested, functional, and fairly secure app in a couple of hours. Casually, if I started with a template, I could have probably written it in 40 hours, at best. It was pretty impressive, but it was a demo, effectively, and I have been fooled before.

Also, I disliked Claude. It was sycophantic even when I asked it not to be. I like my tools to be tools, but that doesn't really have any bearing on this post. I bring it up because I tried them all and ended up with Mistral, which is way better for me and has the benefit of being European and subject to their privacy laws. Also, ya know, not being used to spy on me by my government. But that's another post altogether.

So back to the story at hand. I spent some time during my research time working with Mistral to analyze source code, review data for analysis, and format documents. It was nice. But I kept wondering about actually making software, from soup to nuts. I never thought it would be doable. Testing, review, everything will just be more work than using template code and writing stuff myself.

Then I learned how to do projects. I literally asked Mistral how it liked to do projects and it told me. I suggested some improvements to the way it was laid out and it made them. I started to get a feel for how this could be used. I asked it to do something for me that I had been putting off, which was converting OWASP ASVS 5.0 to a test plan that I use in my application pentesting. I had a short conversation with the console, explaining how I use the ASVS, what kind of document that I'd need to use as the test template.

It created exactly what I needed. In 5 minutes. No notes. Seriously, I have used it for the last 3 tests I have done and it is way easier than the ones I made for myself with V3 and V4. I was, frankly, blown away. But, it still wasn't code.

Then Devstral2 came out. It is Mistral's equivalent to GLT5.3codex and should be able to do the kinds of things that Matt talked about above. So I tried it. I had an actual project to review log records from Azure APIM WAF and recommend revisions to the rules based on the findings. It needed to speak natively to Splunk, process the massive datasets in the logs, store the resultant analysis, and make Azure specific rules that are ready for import.

Took about 20 minutes. All written in Python, with unit tests, and judiciously commented. Needed an API key for Splunk, then ran its own integration testing. Ran the report, decided it could make stronger correlations, figured out how, changed the code, ran all of the tests again.

I watched.

The human take

So Matt's key point is tangential to my experience. He posits that normies should really start to take heed. Are they gonna use Claude Code? No of course not. But their bank will. And their doctor will. And their builder will. And their lawyer will. Folks need to understand that we are really, really close to computers being able to do a lot of things better than us. Again.

My son Adam is an anthropology student and put together a few words about the human take on all of this. You should read that too.

https://adamthropology.ghost.io/a-small-complaint-about-the-current-state-the-world/

I'll leave the anthropology to the anthropologists, but I've got some economics background, and forty years of business ownership, and find a lot to agree with in Matt's and Adam's article.

What I'm doing now

The number one thing I am doing as a software engineer is keeping my feet wet. I already have several code generators that I have written over the years so I still use those to make common things I have to build for customers. But I will take an extra few minutes and see what Mistral has to say. Will I use it? Maybe, maybe not, but I want to see how close it is coming because - as I think I mentioned - things are moving fast. I didn't let internet development pass me by. I didn't let web services pass me by. I don't think I am going to let this pass me by.

As an appsec engineer, I am recognizing the reality. I have been asked to test a double handful of agentic AI bits already and have a blog post incoming on that soon. I have been keeping up with the AI features in the tools I use like Burp Suite by Portswigger. I advise clients as to how to verify code their developers put out using AI consoles and test it with an eye to common mistakes that such tools have been shown to make. (Pro tip: wanna know what kinds of mistakes a developer AI console might make in security? Ask it. The answer has been shown to be right, in my experience.)

In life, I'm learning to herd goats.

No, not really. I don't think there will be a global shift where all developers are replaced with 20 bros with Clause Code. It's not going to happen, probably ever. But I recognize that it is foolish to ignore popular trends even if they don't directly impact me. So I am watching. Keeping an eye on bits that I know might be being automated and taking care with the results they put out on my behalf. Even phone-based order systems. Almost bought a new iPhone the other day calling AT&T because I coughed at an inopportune time. I'm not jumping on a bandwagon for anyone, sorry. But I'll watch and listen.

Why are APIs hard to test?

bill@pointweb.net — Wed, 17 Sep 2025 13:09:00 +0000

Originally, we had web forms. Well, I suppose we still have web forms. The basis of HTTP is request-response, and nothing's really changed there. We've changed how we make requests, but the basic format and idea of the request hasn't altered very much at all. There's still URL parameters and post parameters; it's pretty normal.

Responses are a little different though because sometimes they come back in JSON which is used by a JavaScript user interface. If they are set up in a formal way, they might even be considered an API. That means we've got a JavaScript front-end calling some JSON backend via a standard set of formats that move the data in an expected way, so that we know more or less what's going on.

But you see that isn't really where it stops. Because really anything that is returning JSON in the response isn't a web page right? It's an API call. You're returning data that is to be used by some user interface, in our case it's in a browser written in JavaScript. Fine. But what if it's weird? What if it returns way more than it should, or way less, or way more fields? What if it returns unexpected data when it gets unexpected requests? How are you going to handle that in your user interface?

Recently I wrote about writing failing unit tests. This fits in well with that, because your front end needs to be able to handle unexpected responses from JSON, but more importantly, your security scanner has to be able to handle unexpected responses from JSON. At this time, I have to tell you the future of that happening is bleak.

The issue is one of architecture. The security companies are working very hard to sell you products that will accurately and reproducibly find security vulnerabilities in your code. When they tell you that an API call has a Cross-site scripting vulnerability, you have to wonder if they really understand how the web works. Not to be dissuaded by this they started dividing their products into web scanners and API scanners. Problem solved, right?

As I am sure you can imagine, no, that isn't right. The way we are developing web applications today makes the API a very integral part of the application, which is different from how APIs were built in the client-server days. Having a com component, for instance, with a set of objects you can spin up to get things done is how most architects with experience over longer periods of time think of contemporary web APIs.

But you see that isn't how it works anymore. As time has passed, APIs have become an integral part of the application itself, tied in directly with intermediary products like GraphQL, document databases, and just files in the web application that return JSON that are going to be handled by React or some other JavaScript framework on the front end. Or an app. Or a watch. Or a cron job. Like the diagram I admit I used Eraser for because online diagramming tools hate me.

Because of this, static scanners become extremely confused. It's simply not clear what is risky from an API call perspective and what is risky from a web application perspective. The vulnerabilities in HTTP have not changed. The way an attacker can implement them has, and the security companies are simply not keeping up with this accurately enough to make it a default install of any static scanner worth its weight in anything.

So, what are we going to do? The first thing you're going to want to do is learn the ins and outs of the details of your static scanner so that you can teach it exactly what parts of the application should be scanned in what ways and what kinds of content types being returned have to be looked at in a certain way. you don't need your scanner telling you over and over again that you're missing a cross-site request forgery token in an API call. That just doesn't make any sense. You don't need to know about cross-site scripting in your API call; that is a front-end activity because it's encoding. The scanner just doesn't know the difference.

You can convince the scanner to work with a specific web application, but it is not a point-and-click operation. I found a lot of benefit to manually indexing the site using a tool like Selenium or Burp Suite Professional and then using that matrix to feed into my scanner to do the dynamic scanning from there. are you lucky and you have a nice test suite that the QA team has put together specifically to test an underlying API that's a real API? Fantastic. Proxy that through Burp 2. Give that a try. Rather than feeding the actual Postman project into your scanning tool, try the Burp history instead with your tests in it. In this way, it understands how an individual page call interacts with whatever back-end system there is and doesn't need nearly as much interaction.

The second thing you're going to want to do is handle all of the authentication and authorization pieces in your scanner. I have, no less than six times in the last two years, found scans that have been being run for months or years even, that have absolutely no log-in capability and because of that they aren't fully scanning the application. This really plays in when dealing with an API that uses a separate authentication mechanism from the website itself. the contemporary authentication and authorization systems like Ping and Okta are definitely complicated to scan. There is lots of good documentation out there, but you have to actually get in and read the docs or even go look at sample configurations on the respective vendor's websites.

Third would be looking at the actual output from the scans. I can't believe how much detail is in there that no one really ever looks at. The last several times that any problem has occurred in a scan, I downloaded the full output of the scan, loaded it up in Excel, made a pivot chart, and figured out exactly where it was going wrong. Honestly, that's what led me to points 1 and 2 - realizing that the application didn't know where to go to actually test things and that it wasn't authenticated properly. it's ugly and complicated, with lots of text in it. Honestly, it looks like a web server log. It's hard to dig through, but it brings a tremendous amount of value, not only in solving problems but also in really understanding what that scanner is doing.

there's my two cents as far as dynamic application scanning for APIs. It's not easy. But it can be easier if you just are willing to work with the scanning tool a little bit, realizing it's not just gonna work out of the box. You're going to have to change the way you interact with the tool so it can change the way it interacts with the underlying application

On Failable Tests

bill@pointweb.net — Wed, 27 Aug 2025 16:01:00 +0000

While I am not the High Priest of Unit Testing, one thing that I have seen several times is tests written for compliance uh I mean coverage sake that are effectively unfailable. Things like "assert that system.string does stringy things" and the sort. The sort of tests that are only handled the favorable condition. These are harmless really, in the unit testing space. They make the checkin longer, sure, and eat up SLOC, but in general, pretty benign.

And while I am decidedly not a specialist in unit testing, I can speak to QA quite a bit, because that's usually the excuse developers give when I bring up failing tests. They are depending on QA to order the sfdeljknesv. They should be doing that in their unit tests.

In the application security world, unfailable tests are a real issue. How do unfailable tests make a difference in the security world? The issue is: there is never a view into what happens when the application fails, even at the unit level. That's kind of specific, but you can see generally what I'm talking about. How does the application respond if something isn't available, doesn't happen, doesn't add up.

For a glance into that a little bit more seriously, I strangely enough found a post by Terence Tao, a prominent mathematician who wrote about unfailable tests in the premises you give an AI before you set a specific prompt. Kind of a built-in prompt misengineering of the interaction with the AI, except not at a chatbot level. With these mathematician people, they're speaking a little bit closer to the metal and using the AI in the old-fashioned sense of machine learning with a big dictionary of stuff to use.

What Mr. Tao took out of this was that genAI is specifically lacking a 'failure mode' where it just tells the user "I'm sorry Dave, I can't do that" and gives the user an option to change the query. Think of a regular search engine. If you search for something really obscure, and it isn't in the index, you get zero results. The search failed. That is an important part of the entire user interaction. The tools he uses have features that enforce a failure mode, which lets him move his debugging to a more detailed form.

When I go to look at applying this to application security and unit tests, I think of the hard-to-isolate problems that the lack of a failure mode is causing in generative AI. When a lawyer submits a court document that references cases that don't exist, that's a breach of sorts. The system has failed the user because the system failed to fail.

Let's look at a specific example. It's a stupid simple example, but it illustrates the point. Imagine you have a method that divides two numbers, like my excellent Divide function:

public static double Divide(double numerator, double denominator)
{
    if (denominator == 0)
        throw new DivideByZeroException("Denominator cannot be zero.");
    return numerator / denominator;
}

More often than not, we will follow the happy path with our test and make sure the division is right, ya know?

[Fact]
public void Divide_SixDividedByTwo_ReturnsThree()
{
    int result = TimeHelper.Divide(6, 2);
    Assert.Equal(3, result);
}

This is all well and good. We gave it numbers, it gave us the quotient. We made sure it met all of the expected input, right? Or did we? Aren't there two, known, expected results to this method? You bet, we have defined an error condition, and that should be tested for too.

"Bill, is this going to get around to appsec before the heat death of the universe?"

Yes, it will I promise.

When a system misbehaves, it is extrordinarily important to know how it will react. Users will just see errors, but attackers will see opportunity. I talk about this a lot in my information disclosure talk. The attacker causes a fault in the system that returns errors, they research those errors, and then exploit the findings.

When I perform application vulnerability analysis, I stop when I see an error from a DBMS. If I got an error, I will be able to exploit it. When I see an error with a stack trace, I stop. I know that's exploitable too. It's as solid of a bet as there is in the pentest biz. Making sure that each individual unit in an application fails in a known manner when something really weird happens is key. It prevents the creation of opportunity.

So the next time you are slotting in tests for a new function think about the lizard. And maybe buy him a beer.

Stay frosty and test your apps

bill@pointweb.net — Mon, 18 Aug 2025 18:50:00 +0000

As an independent developer, I live and eat and have a roof because of billable hours. For many, many hears, my strategy had been to stay calm and bill hours, even in the face of weird situations, and the advice I gave to customers more or less led to that. Don't worry, let's build it. Don't worry, let's test it. Don't worry, let's break it and make it something else. Stay frosty.

But now I am changing my tune a little bit. This is because of a couple of factors. First, the "go fast and break things" strategy had gotten its ultimate test in the federal government of the US and failed totally. That strategy is over for me, I am not recommending "well let's just try it and see" any longer. Done with that.

Another impact was The Devil Never Sleeps by Juliette Kayyem. This book is about actual real emergency preparedness at the strategic level. It, not to put it too lightly, has changed my language about preparing for things to go wrong. Key to Juliette's teaching is the horizontal graph of time, where an event or "boom" is in the center, and then there is space on either side of the boom. Her primary goal is to change where we put effort, left or right of the boom. It's not just emergency preparedness, it's emergency management.

Remember "shift left"? Corporate buzzphrase from 20 seconds ago or whatever, I think it's already 'out'. Anyway, that is where I am headed in the application security space. No more "stay frosty and test your apps". Proactivity has shown over and over again to be the better solution in my estimation. Finding bugs before they ever get into the code base or never coding bugs in at all. Putting the effort to the left of the boom.

To that end, I have started recommending static analysis tools to clients with developer tool plugins. The difference? Education around that fact. Snyk does a really good job at this. Not just throw the tool out there and assume everyone will magically get it just because it makes a red squiggly line. Not just training on the tool, but real security education that just happens to use the tool. Developer education around the toolset, using their real source code, their real source code control system, real talk.

Another piece that I have always given a polite nod to but haven't really pushed is non-functional security requirements. I don't care if you are all fancy and agile and scrum and whatever the latest weird project management strategy is, at some point you need to write down what the software you are building is going to do. If there is not a list right along side describing the non-functional security requirements, requirement gathering is not complete. The OWASP ASVS is a great resource for this. I already use it on the other side, as a test plan, it really is designed to be used on the front side of a project, defining the non-functional security requirements before you start.

Front load your security. Keep it left of the boom. It's the fastest, easiest path out of this mess we are in.