More Supply Chain Attacks

Posted on March 21, 2025 by way0utwest

The latest code supply chain attack isn’t a direct attack, but a failure of a system designed to be efficient. There is a Go (Go-lang) module that had a malicious module inserted into it years ago. Someone caught this and removed the module from GitHub, but Google had cached this and has kept it alive for the last three years.

This attack worked because it relied on the Go Module Proxy services, which prioritized caching. Even when the source changed, the cache wasn’t invalidated or reloaded, which seems like a major ovesight or even larger design flaw, but I know everyone trying to maintain software archives at scale tends to cache a lot. After all, so many developers might load modules in their daily work, in CI, etc. that caching matters.

However, the bigger issue is that criminals are getting more enterprising and aiming for supply chain attacks where possible. One would hope that any PRs (pull requests) are carefully examined, but the truth is that a lot of people might depend on their unit tests passing in a CI build. They are not necessarily looking to see if anyone has actually entered malicious code or even poorly written code. I can see some people worried more about code structure and naming (or tabs/spaces) than what the code does. Imagine seeing a change that looks innocuous at the top of a file, all tests pass, and you merge the change, but didn’t notice there was a few new functions added below in the file because they’re not obvious in the UI.

Someone maintaining a popular code repo as a side project might be fooled here, but if this were in a corporate repository we might be even more susceptible. We have more reasons to trust the PR isn’t a problem if the code passes tests inside of an organization. After all, who things criminals might insert code into their corporate repo? Not many people do, but we’ve seen quite a few successful supply chain attacks in the past. Who knows how many more we don’t know about.

Security is a hard business, and when it’s extended to the code we write, it might even be harder. I know there are security scanning solutions you can integrate into your codebase, but those detect what they know about and criminals keep finding new ways to attack us. Ultimately I think we depend on code maintainers carefully examining PRs from outside their circle of trusted individuals, and even then, things can slip through.

Some days I think it’s truly a mad, mad world.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Comments Off on More Supply Chain Attacks

Advice I Like: The Main Thing

Posted on March 21, 2025 by way0utwest

The main thing is to keep the main thing the main thing. – from Excellent Advice for Living

We can summarize this advice as focus on what’s important. I too often see authors and others get distracted from the main point on which they are writing. I see this in meetings when people start to speculate about something related (or even unrelated) and forget the purpose of the work.

This becomes an even bigger issue when someone goes off to work on a project for a period of time and drifts away from their original goal or focus. You might think you don’t do this, but I bet most of you do. I know I do. I sometimes start to change my focus, thinking the current thing I’m working on is more important than the main goal.

An example is that I might be working on a new presentation. I’ll start to outline the talk, add some bullets and notes, maybe think about demos, etc. At some point, I get distracted with which pictures make my point and I start to waste time on choosing pictures, rather than remembering that the point of the talk isn’t a picture, it’s to teach something. The picture might help, but it’s not the most important thing and it’s not where I should spend a lot of time.

Today’s interruption culture of having notifications, slack, email, etc. available on devices makes this worse. The large amount of things we often engage in at any one time also makes this hard.

Focusing on what you want to achieve and keeping that in mind is important. For presentations, I often put my abstract in the first slide notes, so that I remember what I’m focusing on. For coaching, we often list a few things we want to work on, and as we run drills or evaluate the practice we can look back and see where our focus is. What was the main thing.

Keep the main thing the main thing.

I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

Posted in Blog | Tagged , | Comments Off on Advice I Like: The Main Thing

DATEADD Truncates the Number Parameter: #SQLNewBlogger

Posted on March 19, 2025 by way0utwest

This was an interesting thing I saw in a Question of the Day submission. I hadn’t thought about the issue, but apparently DATEADD truncates values rather than rounding them. I’m not sure why that is the case, but it is.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

The Scenario

Imagine that I have someone enter a value for the number of hours to include in a report. I enter 5 and the report divides this in half to go back 2.5 hours and forward 2.5 hours. I run this code at the top of my code block:

DECLARE @hours NUMERIC(4, 2) = 5;
DECLARE @start DATETIME, @end datetime
SET @start = DATEADD (hour, -@hours / 2, GETDATE ())
SET @end = DATEADD (hour, @hours / 2, GETDATE ())

Now, what do you think are the resulting start and end times? I’d assume this works and the function sorts out how much of an hour is .5 or .4 or whatever.

Here’s the interesting result. Look at the time interval in the end result.

2025-03_0091

It’s 4. I entered 5 hours, but I get 4 hours. I bet a lot of us would let this bug slip through as reading the datetimes we’d miss this wasn’t actually 5 hours.

Apparently DATEADD actually truncates a non-integer value. The parameter notes that the 2nd parameter, the number to add to the date value, resolves to an integer. It also notes that DATEAD truncates, not rounds, values that have a decimal fraction.

Those are two very important distinctions. That could result in calculations that are way off from what people expect if you are trying to include data in a query and you are trying to do parts of time. You might need to separately calculate all your different date/time parts.

If you need to do fractional work with dates, you can’t use DATEADD.

To me that seems lacy, but is it? Let me know.

SQL New Blogger

This is a short example of something that a person pointed out to me, and I never knew. I decided to make a quick test (the code above) and then write about this. I could have included other examples, or shown how this might mess up different situations in my code.

You could do the same thing in 30 minutes or less and point out an interesting piece of knowledge that your future employers might find interesting. They might even want to interview someone that learns things like this.

Posted in Blog | Tagged , , | 1 Comment

Lower Your Attack Surface Area

Posted on March 19, 2025 by way0utwest

It’s no surprise that our systems are under attack by all sorts of criminals. Some organized, some opportunistic, some just aiming for vandalism. We need to protect our digital systems to prevent issues, and a part of better protection is reducing the number of places that are vulnerable. Those places include databases.

This article discusses the rising costs of data breaches and the increased frequency of attacks. It also examines the increasing number of regulations that are demanding proof of stricter security measures. It can be hard enough to defend production systems, let alone protecting dev/test environments. I see an increasing number of organizations that limit access to production systems, even to the point that this impedes some of the daily work habits of technology professionals, but that is probably a good thing. Too many of us are too lax when it comes to security.

There are lots of approaches to getting better at security, but one of the easier ones is to avoid making copies of sensitive data. About half of you (I hope it’s not more) still use production restores in dev/test environments. That’s a tripling of the places your data could be attacked if you restore a database to a development server and a test server. If could be even worse if you make more copies.

An easy solution in today’s world is to build a better test data management process for either anonymizing and obfuscating your sensitive data or generating synthetic data. Both have their challenges and I suspect that most organizations need a combination of both approaches to both protect their data as well as build better software for their customers. After all, a huge amount of bugs are data related, where developers have not tested their software against enough different data elements. Both synth data and anonymized data help here to produce enough different edge cases that your testing is thorough enough to increase quality.

Of course, you need extensive testing, which means automation. Ideally an automated DevOps flow that subjects your software to increasingly complex tests as it moves through your pipeline to ensure it’s ready for release. This also means a good set of test data, not only for QA, but for automated tests. You need a test data management strategy.

Securing digital systems is a complex task, but we ought to try and make it easier on ourselves by developing good habits in how we manage both access and by limiting the copies of sensitive data.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Comments Off on Lower Your Attack Surface Area