Security Confidential S9 E7 Eric Allard

Manoj Tandon: Hello everyone, this is your host Manoj Tandon, and welcome to another episode of Dark Rhino Security Confidential. Today we are honored to have Eric Allard join us. Eric is a phenomenal talent in the world of cybersecurity, application security, and development. He is also an entrepreneur; he’s currently the CTO of SOOS, a software technology company. He has 15-plus years of experience in leadership, business strategy, and software team transformation with a very broad set of skills. On top of that, he is a software engineer and, more importantly to me, he actually has a degree in mechanical engineering, which I find some commonality in, which is awesome.

Welcome to the show, Eric. Thanks for being here. I appreciate you joining us today.

Eric Allard: Thank you so much, I really appreciate it. And hopefully, you cannot hear the jets that are taking off over my head.

Manoj Tandon: No, the noise cancellation is actually pretty good. It looks like that technology has come a long, long way. So, let’s dive into this a little bit. You know, it was an interesting profile when we were researching you—some of the things that we came upon. So, your foray into entrepreneurship: tell us a little bit about that. How did you get into that and what drove you there?

Eric Allard: Yeah, it wasn’t on purpose. I think my post-high school career path was a little non-traditional. I was in a trades apprenticeship. I then started college for mechanical engineering. I took a longer path to get to graduation, switched to software at some point, and at the end of my senior year, I had made friends with another gentleman who was a great programmer and said, “I don’t really think I want to get a corporate job, but what if we started a business?”

And we did. For mine and his first jobs out of college, we started a consultancy, and we did that for six years building websites, eventually early mobile applications. We did a lot of bank software. So, it was not how I planned it, but it’s how I got into software.

Manoj Tandon: Banking is an old industry. Why banking?

Eric Allard: It wasn’t intentional again; it wasn’t on purpose. We were working with a company who did check-processing software. This was back in the early 2000s where there was a new law requiring them to not trade paper checks anymore. I think it was called Check 21.

So, instead of banks sending cargo planes full of checks every day across the country to say, “I owe you this much and you owe me this,” they came up with some cash letter standard. We were helping a company because we knew more modern languages like .NET, and they were all COBOL and mainframe folks. So, we were helping them—they called it server-to-server applications. We helped them work on some of those integrations.

Manoj Tandon: Fantastic. Were they fairly open and receptive, that market?

Eric Allard: I have to assume, and my fingers are very crossed, that things are more stringent today. I mean, it just was a little more of a Wild West. I can’t imagine hiring some young 20-somethings with no background checks to come do this.

I just don’t think anyone would do it now, but it was an opportunity that we were fortunate enough to have, and that’s what got us started. I went on to other businesses, but I’ve always stayed in software careers, other than my stint as a stay-at-home dad, which was kind of a more recent career thing.

Manoj Tandon: Well, let’s chat about that. I mean, you’ve actually put that publicly on your LinkedIn profile, which I think is a very good thing. It says a lot when someone’s willing to do that, but why is that important to you?

Eric Allard: There’s a number of reasons. Selfishly, it helped me figure out more about what I’m maybe good at and what I’m not. It’s a very hard job.

If you’re ever going to manage people and parents, unfortunately, I don’t think you can fully understand what being a parent entails without being a parent. By being the one who stayed with the kids, there’s a lot to it. Sometimes there’s not a lot to it, and that can also be very challenging—just dealing with what I should be doing with my time, how I am doing the right thing for my kids, and sometimes being bored or wondering what’s happening and what will happen to my career when I go back.

As a manager of people, I certainly have thought a lot about how in my prior jobs I managed people with kids, and how I see things very differently now. It’s a tough job. It’s a job like anything else—don’t get me wrong—and it’s not easy.

Manoj Tandon: Let’s switch back to that for a second. From entrepreneurship, you went into the corporate world. Was there a reason that you went there? Did you sell your company or what happened?

Eric Allard: It was right during 2011. We had weathered the 2008-2009 recession, but it was hard. In any sort of a consultative business, you’re spending a lot of time making sure you have a pipeline. There was other personal stuff going on in my life, and someone was recruiting me to come work for another local business that we had done some consulting for.

That became my first real corporate software job with a substantial staff, and I kind of stepped away from being a software engineer and became a manager. That was a whole other big experience for me. Doing the business where it was one other person and me in a nice office—that was it for six and a half years. It was him and I and the phone, and socially, I don’t know that I even recognized how much that hampered me until I started this new job. It was like the world changed; everything changed color like Dorothy in The Wizard of Oz. I was just like, “Wow.”

Manoj Tandon: But do you miss the freedom?

Eric Allard: No, I think the freedom thing is kind of a false narrative because there’s always a boss—that’s either your customer or your own drive to accomplish something.

I think as I’m—not old, but I’m in my 40s—I think freedom is what you make it. I’m fortunate enough that I feel like maybe I’ll have to do something else someday, but having your own business certainly isn’t necessarily freedom either. There are a lot of responsibilities and considerations.

Manoj Tandon: Absolutely. You’re probably the first one to make that comment on the show, but it’s 100% true. There’s always a boss. Everybody has a boss; it’s just the reality of what it is. It doesn’t matter—even if you’re the President of the United States, you have a boss.

Eric Allard: Yeah, there’s a boss. Something’s helping to shape those decisions substantially more than just what you want. I think that’s the key thing to remember.

Manoj Tandon: Very much so. You’ve brought up managing people a couple of times, and I think I was reading on your profile or an article that you had posted that when you’re actually interviewing someone, you don’t like to be dismissive of them; you always want to give them real feedback.

I thought that was interesting. Since we brought up management, I thought I’d ask: why do you think that’s so important rather than just saying, “Thanks, but no thanks”?

Eric Allard: Because I think most people want to do better. I also think in some of those early discussions, you can really just base it on—you don’t have a history with the person. They didn’t do something that made you mad one day; you’re not carrying any baggage. It’s just, “Okay, based on everything I’ve been able to learn through the credentials and the resume you provided in this discussion, or maybe the few prior, here’s what I think would work best for you, even if it’s not here.”

Managing people is hard. If you really want to do the best job you can, that’s the hardest thing I’ve had to do in my career since being a software engineer: learning how to work with people and coach people. I’ve done plenty of things wrong, especially when you manage a lot of people.

I think what you maybe don’t notice at first is so many things are proxied through others. You can’t have direct experience with everything that everybody on your team is doing firsthand, and it just gets lost in the fog of business, the fog of everyday tasks.

There’s not a lot of hearsay in an interview. You’ve talked, you did what you needed to do, and if it’s not a good fit, hopefully you can tell them right there, and if not, soon after with a follow-up.

Manoj Tandon: Before we get to software application security here in a second: do you welcome—and I’m asking this for the benefit of our listeners because some of them are searching for jobs right now and making career transitions into cybersecurity—do you welcome a lot of questions from them?

Eric Allard: Yeah, even though they may guide you to opinions that are very different from your own. You learn a lot about people that way. I still remember opinions I gave in some of my early interviews and just maybe how poorly delivered or untactful I was when I was 20 years old, and that’s okay.

Questions are a way to show your creative take on something that maybe they just wouldn’t expect. It doesn’t have to always be about the job; I like to know whatever people want to talk about. I think that can really drive a discussion and give you a sense of how they interact and how they handle a difficult situation.

I’m like anyone else; if people reach out to me cold on LinkedIn, you get inundated with stuff, but it is really worth it. You get people’s attention. One of the people that I remember clearly reached out to the president and sent a resume, and he sent it to me, and I was like, “All right, I’ll talk to this guy.”

It was a great fit. The person had a personality and the attitude, so take a chance, for sure. Send it out there and see what you get.

Manoj Tandon: There you go, that’s great advice. Let’s switch gears a little bit and talk about SOOS, which is the company you’re with right now. What is SOOS all about and what are they trying to accomplish in the market?

Eric Allard: SOOS was founded a couple of years ago by a pretty senior engineering mind who I had worked with at a prior business. It is made up of a number of people from this prior business. We used to do retail grocery software.

Manoj Tandon: Interesting.

Eric Allard: Yeah, there’s a lot of cool stuff and more parallels than you would think. At the end of the day, there are security-specific things and problems you need to solve, but you’re putting together what I would call an enterprise application, meaning there are certain capabilities that are expected if you’re going to sell something commercially.

All of those are problems that you’ve solved whether you’re making retail grocery platform software or cybersecurity software.

SOOS makes, specifically, a proprietary SCA tool, which is Software Composition Analysis. I’ll explain what that is in a minute. Also, a DAST tool, which penetration testers might use, and the glue that connects a lot of those things.

The differentiator is we are trying to create a product that is purpose-built for small and medium-sized businesses and that’s affordable. It’s a new take on something that’s existed for a while that a lot of people haven’t started doing yet.

We’re trying to, as we say, democratize software security. We’re trying to make this solution accessible to the tens and hundreds of thousands of companies that may build some software but don’t exactly know what’s in it. That’s our goal: to try to get that capability much more broadly available.

Manoj Tandon: Does SOOS stand for—is it an acronym for something?

Eric Allard: It’s not. If we were really creating an open-source product itself, you know, “Open Source” or something like that… no. It’s not the most amazing origin story. It’s, I believe, some Spartan, maybe semi-mythological figure that was a protector figure.

Manoj Tandon: Accessibility is your avenue of democratizing software, right? You want small-medium businesses—and there’s a lot of them—that are developing very niche applications out there.

But there is—you hear that term “MVP” thrown around a lot in the industry, the “Minimum Viable Product.” I’ve heard it a lot from even investors, that they want their companies to get to that MVP and get it to market.

Is there not an inherent conflict, an obvious conflict, between building for security, testing for security, and designing for it up front versus achieving the MVP?

What’s your advice or how do you resolve that?

Eric Allard: Let’s be honest: I think there is, but there are a lot of things where I would say, “So what? You still have to do it.”

We have a local company named Beta Technologies. They’re really interesting. They make electric planes that can vertically take off, and they’re working with UPS and the military and all kinds of people. They have lots of interesting technology with charging and flying an electric plane. Super cool, right?

I am not particularly close to their business, but if I said to you, “Manoj, Beta is really cool. Isn’t there an inherent conflict in making this thing not crash versus making it quickly?” you would say, “Yeah, but I have to make it not crash. I have to make it safe enough that this will safely carry our pilots and someday whatever cargo is in it.”

So, yes, there is some conflict there, but that doesn’t mean you can’t do it. And if it were painless and inexpensive, I don’t think people would resist.

Just like test-driven development, or even a couple of decades ago, on small projects people might say, “Well, why am I going to use source control? That’s expensive, there’s only four of us, and it’s a bunch of overhead.”

No one would even consider that now. GitHub is free or cheap. A lot of these things have just become de facto. In the case of TDD, for example, it’s maybe not universally accepted, but people understand there are certainly a lot of benefits to it.

People are going to use a source control solution. I think a lot of these fundamental security capabilities will be commoditized, and they will become a frictionless experience so that someday you wouldn’t even consider talking about a development cycle—small, medium, or large—that didn’t include it.

Manoj Tandon: Do you have any metrics or anecdotal evidence on how much time it adds to a timeline in the development cycle when you are considering AppSec as part of this process?

Eric Allard: I don’t have anything empirical.

As a sidebar, I was quizzing ChatGPT yesterday and then fact-checking some of its things. At first, I was like, “See, this is why this will never work, because I can’t find any evidence of that.” Then, as I dug in for an hour, I was like, “Oh, no kidding, they’re actually—this is pretty close to being true anyway.”

I can’t throw out a great statistic, but I will say, if we bring it back to being really small: starting small, you can do this in a stepwise motion.

If you’re a company that already has thousands of employees and thousands of projects and you want to start an AppSec program, yeah, you’re going to have to do it in a crawl-walk-run manner. You’re going to have to pick a couple of newer projects that you think are in good shape and start with those. Learn the ins and outs, understand your team’s process for how you’re going to triage issues, and determine if something needs to be addressed or not.

If you’re a little team or one person, it’s actually a small lift because you’re starting with nothing. If you’re doing it from the very beginning, you’re going to keep up with it as you go along, as long as there’s a solution that is simple, easy to set up, and that you could actually buy.

There are some free and open-source ones as well; they just may require more of your time and energy to get going. That’s the trade-off.

Manoj Tandon: Sure. Again, just attending some of the local tech council events or technical events with startups that happen here in our region, we see a lot of small software companies that are developing very specialized pieces, whether it’s components that go into medical devices or component pieces that are going into a specific robotic application. These are really niche things, and these development teams aren’t super large; they’re like 5, 7, or 10 people.

This is purely anecdotal on my part—so take this with a gigantic grain of salt, and if somebody fact-checks it, please put it in the comments and let us know what the real numbers are—but generally speaking, we have not seen security for those niche applications be at the forefront of those teams’ minds. I guess what I’m trying to say is: I don’t know that those teams are beginning with security as a critical component in mind.

Eric Allard: I don’t disagree with you based on what we’ve seen from the market and from what we’ve seen from our early customers.

Here’s where I think we will be. Let’s pick a time in the future: 10 years. Then it may not be front of mind; it may just be accepted as the de facto standard.

If you want to talk about this very moment, I think I would roughly divide things into two categories—maybe only one—but the biggest category is someone is compelled to do this for a compliance effort, or because of a merger and acquisition. Those are things where you need to have an assessment of the software using known vulnerabilities and the licenses you’re relying on in your software.

Or, you are a young technology company that understands the value and that there’s some substantial insurance you can get by not having to worry about some of this right out of the gate.

But mostly, businesses that are doing this do so because they get to a point where they recognize someone’s telling them to do it—either their boss or someone that wants to buy them. If you go back to “who’s the boss,” there’s always a boss somehow and you’re being compelled to do it. But I don’t think it’s going to be like that for much longer.

Manoj Tandon: I really appreciate your candor on that. Let’s talk about those tools. You know, what are some of these software supply chain tools? Which ones work and what’s in that space?

Eric Allard: There’s a lot of stuff, and I don’t want to say any of it works or doesn’t work. Sherlock Holmes looked at a lot of clues before he found out who did it, and he had a lot of help from Watson.

Let’s break out a few of the big categories. We do SCA and DAST. I like to say SCA is like the nutrition label: “Here’s what’s in it.”

If you’re thinking about a recipe, it’s the ingredients list. Then something like SAST, Static Analysis, would look at your code. You could have an ingredients list, but you wouldn’t necessarily be able to make the recipe; you couldn’t make the cake just because you knew it had this much flour and sugar. You would need some instructions. SAST would help you look at those instructions or your code.

There are binary analysis tools. That’s like the cake came out of the oven and someone looks at it with a microscope and says, “Based on the molecular structure, I think this was flour and butter and water.”

There are certain binary analysis tools and runtime agents, which are watching the byte-level flows on a particular machine looking for something that it thinks—based on the way this thing’s accessing memory, or how it’s trying to allocate resources, or where it’s trying to exit the machine and get out onto your network.

That’s all just the software runtime and software supply chain aspects. That’s not even considering things like endpoint detection and tools you could be running at a more network hardware level.

You want to do the best you can with what you can put into place, and I think it’s going to depend on what kind of business you are, what your industry is, what you’re creating, and what your technology is.

If you don’t make software, some of those things don’t apply, but you still may need some of these tools because you’re an IoT vendor and it’s going to be communicating.

Actually, I’m going to contradict myself: you still want to do that as much as you can. You just may not be the one creating that software Bill of Materials for whatever is in that device you created. You’re going to rely on your vendors to provide that to you, and you may find that they can’t do it yet.

Manoj Tandon: I often hear people talking about the outputs and the action items out of software tools. Let’s take SBOM. Are you familiar with it?

Eric Allard: I’m not personally familiar with it, but I know what it is. It’s the software world’s version of the bill of lading or the bill of materials that might come with a shipping container: “Here’s all the stuff that’s in this box.”

There’s been a lot of talk and activity over the last year about more regulation requiring the software Bill of Materials. Say you’re going to provide software to a government entity; some big industry players are pushing back, probably because it’d be a lot of work for them to create these documents.

One of the narratives is, “Hey, we don’t really know if this is the right way to solve the problem. We don’t really know that this is the right format. We haven’t figured out all the details.”

That’s fine, but I don’t know that the answer is to stop trying to figure out what you’ve got. It’s the journey, not the destination.

Doing the audit and having an understanding of what’s in your software or hardware is the thing that’s going to take discipline. Whatever format you share that information with is secondary—not really that big of a deal, in my opinion.

Manoj Tandon: But Eric, would clients—even if they’re government clients—really have the technical wherewithal to understand that SBOM and really make a judgment call on it? Because a lot of it is also going to get back to not just what’s in there, but the architecture of how those components interplay with each other.

Eric Allard: Yeah, and there are aspects of SBOM where, for instance, you can use VEX, Vulnerability Exploitability eXchange, which may become used more prominently.

You may have to attest, “Yeah, my software has that, but we never call this routine. It’s not actually a vulnerability in our software.”

Whether or not you have the expertise to make a decision, you still need to know. If you’re a diabetic and you’ve just been diagnosed and you don’t know a lot about what that means from a diet perspective, your doctor is going to give you materials and teach you some things, and then you’re going to become more of an expert on things you care about in the food that you eat and how it impacts you.

The reality is people are going to have to become more educated and have a better understanding of what matters to their business and what is in either the software they’re making or the software they’re receiving.

Manoj Tandon: Let’s go down that… this is a big rabbit hole.

If we peek into that rabbit hole—not all the way, because we’ll never come back out—if we look at the way software development is done today, you are using a lot of open-source, off-the-shelf components. For example, there’s so much software developed on Java, right? Which is now an Oracle product, and it’s ubiquitous.

You don’t know what security vulnerabilities reside in that. There have been a couple of significant ones that have come up, zero-days that nobody really knew about.

How do you, when you are doing a development process on software, really mitigate for that? How can you even mitigate for that? What’s the best that can be done? Because I don’t think we’re going back to a world where everyone’s developing all the libraries from scratch; they’re going to use what’s available to get into rapid software development.

Eric Allard: Step one: having an inventory of what you have is helpful. Then when there is a new announcement that something is vulnerable, you don’t have to scramble to understand if you’re affected or if you’re even using it. You can look at your inventory and say, “Oh geez, we are,” or, “We’re not, but transitively through something else I’m dependent on, its dependencies are using it.”

Okay, now you know that you’ve got to dig a little deeper. From there, you may have to upgrade or not to remediate a vulnerability.

It’s going to take some decisions that play into more of a classic software engineering problem. How did you build this thing? How are you depending on these third-party things? Is it hardwired in? Do you have abstraction layers? Can you rip and replace this? Can you not? Are you at the whim of whoever created this dependency to fix it and patch it?

Just because you’re not writing it doesn’t mean you’re absolved from how responsibly you use something. I always think: what kind of an approach did you use to incorporate this into your bigger enterprise application?

That’s just responsible software engineering practice, right?

Manoj Tandon: But you could be very responsible as an organization and follow good practices, but you still can’t ultimately guarantee that nothing is vulnerable.

Eric Allard: No, you can’t. And you may be stuck for a while. You may have to disable a capability in your application; you may have to put in other mitigating things like firewall rules. I don’t think that always works, or it’s not sustainable, or you could make all kinds of other problems doing that stuff.

There’s no one answer. You definitely need to know, though. You need to know so that you can try your best to MacGyver. There are always going to be times in any trade—whether you’re building software, or you’re welding steel—where you’re going to need to take some sticks and duct tape and temporarily work around something.

A lot of the instances come down to: awareness is step one, because you can’t react to what you can’t even measure.

Analogy-wise, it’s just like looking at building a house and all of the things that you could find when you redo a 100-year-old house. It’s endless possibilities. There are some things you could look at as an inspector to have some hints. What’s the water table like? Is this neighborhood wet? Do we have carpenter ants? There are things you can look for, but there’s stuff you’re going to be surprised by.

Manoj Tandon: What you just said about awareness—that’s interesting to me. That’s a good reason to have an SBOM, because it does potentially daylight some things and bring things to the forethought that may not necessarily have been there.

What’s the role of compliance in that? Do you think compliance frameworks actually make a difference? And I’m saying it from the point of cybersecurity because we’ve seen it: you can check all the boxes and still not have good cybersecurity.

Eric Allard: At least in my personal journey, if you’re trying to do the right thing and you’re making a good faith effort during those processes, you’re going to uncover things. You’re going to pull off that piece of sheetrock and be like, “All right, that’s bad; we do need to do better with this area.”

Compliance efforts are going to have very prescriptive controls in some cases—PCI, SOC 2, whatever. Section 6.5: “You must remediate all critical and high vulnerabilities within N days.”

That’s why a lot of people go look to do it. But again, it’s the journey, not the destination.

I promise no one is really doing 100% of every single control in some of these big frameworks. However, I also know through my own experience: when you really go and look at what it’s asking and think about what it’s trying to accomplish, you’re going to do things better than you were.

You’re going to make improvements, you’re going to make stepwise changes, and you’re going to put things in place so that next year this is simpler or you are more prepared.

For most people, it gives you a path and some formal guideposts to try to keep you on the rails. But it’s not a guarantee of good software. Like any other 10-step plan you’ve ever seen, you could follow everything and it doesn’t guarantee that you’re going to be successful.

Manoj Tandon: You said something there: if your efforts are in good faith, then those frameworks can make a lot of difference because you are inherently trying to do the best you can.

But it also brought to my mind scenes from the original Jurassic Park. I don’t know if you’ve seen it, where that guy shuts down the fences and has to reboot the whole thing. It wasn’t designed to do it section by section; it was like, “We got to do the whole thing.” It was just a mad rush.

It sounded like those guys were just trying to get the damn thing to happen and get people to buy tickets, and how it worked was an afterthought.

If you’re purely in the MVP crowd, you might be more in that circumstance than the good faith crowd.

Eric Allard: But in the MVP crowd, when you’re not a huge company, when you look at a lot of these controls, the scope is much different. If you’re in the MVP world and have five people, trust can count for a lot, and there are not as many things to keep an eye on. Communication is easier. It’s a very different ball game than in a 50-person business.

I think there’s still something there, but you’re going to have a much more grassroots approach to things than if you were a bigger company. If you have to be SOC 2 compliant and you’re an MVP product, that’s a tough position to be in.

Manoj Tandon: That was very politely said.

Eric Allard: You can do it, and I think there are a lot of services now that substantially ease that burden. You can be provided with enough people with experience to say, “Look, for your business and how small you are, this is what you should be thinking about and how you can accomplish this.”

I’m not a compliance expert. I do know from our business’s space that that is a reason people come looking for tools like ours.

Manoj Tandon: Give us a couple of use cases for SOOS. Why do people come looking?

Eric Allard: The original reason this tool was built: our founder was going through M&A and trying to use some of the legacy stuff on the market. This was about seven to ten years ago. It was very cumbersome. That was his inspiration: “Someday I’m going to make something that does this better, and it shouldn’t be so complicated or expensive.”

The software world has changed a lot since then, too. Package managers and more modern languages have a lot of advantages for how to find and learn about your dependencies.

Also, license understanding from a legal perspective: what open-source software are you using? If you want to get acquired, someone’s going to ask. That’s a reason.

The vulnerability aspect is a natural extension of that. If you know all of the things that you’re using, there’s a lot of data out there—open and otherwise—that you can comb to figure it out.

Obviously, this isn’t all the vulnerabilities in my software because we don’t know all of them. There are lots of undisclosed ones, but of what we know, how many apply to this bundle of stuff? This Betty Crocker cake mix? If I look at that ingredients list, how many of these do I need to worry about or look into more to see if I’m relying on it?

If I’m not using the optional sprinkle pack, then I’m not vulnerable. You’re going to have to make some judgment calls.

Use cases: vulnerability finding, but also remediation. The tool will tell you, “Here’s newer versions that don’t have vulnerabilities.” It integrates with issue managers and so forth.

And then the last step: what is the output of this process? You do this stuff continuously on every commit. You integrate it into your build cycle. It’s very simple.

When you need to know, “Did we ever have that?” you can go back a month and look. “Oh geez, were we using that thing and then we yanked it out, but we temporarily had this?”

If you’re a little company, you’re probably not going to audit that, but the point is you have a record. You have an SBOM for every cake you ever baked. You can go back and look at this build and see the ingredients list.

Again, going back to the journey, not the destination: if the destination is that someday you’re going to have to give someone an SBOM, if you’ve already taken the journey and set up some tooling in your build process, you’re going to have learned a lot more about how easy it is to update these dependencies or potentially remove them.

How frequently are the maintainers contributing to these packages and updating them? There’s a lot of good developer hygiene that comes along with this stuff, like, “Oh geez, we’re quite a few versions out of date.”

That will all be apparent in these tools.

Manoj Tandon: If you’re comfortable sharing, from a cost perspective, how big is the breadbox for a small business to get engaged with SOOS?

Eric Allard: It’s very inexpensive. It’s $199 a month if you want both of our tools—DAST and SCA. We have a Community Edition, so if you’re an open-source project, you don’t have to pay anything. We will give you the full license, but we have a no-friction signup.

Some other folks will give you a free license for open source but you have to fill out forms and get approved. We just require you to have a public GitHub repository and that’s it. We’ll ask you to put a little badge on your readme, and you can use it for free.

We’re going to add Bitbucket and GitLab support as well. Right now it’s GitHub, but soon any of those SCMs could use our stuff for no cost if you point to your public repos. And we’ll make you an SBOM and all that stuff.

Manoj Tandon: I think that’s motivation for people listening—free! How do you get the price right?

Eric Allard: We want people to know that this is a thing. We wanted to get the word out, and if you want to use it for your business, it’s extremely affordable.

Manoj Tandon: In the last minute here, I know we’re at the hour, I just wanted to ask: do you have any events? Any publications that you want to talk about to inform our listeners?

Eric Allard: We’re going to be at DeveloperWeek out in Oakland in mid-February. I’ll be talking there on Valentine’s Day. We’ll throw out some passes for that. Those are the big upcoming things.

Manoj Tandon: That’s fantastic. If people want to get a hold of you, what’s the best way to do it?

Eric Allard: SOOS.io. S-O-O-S dot I-O. Just come to our website; it’s very straightforward.

Manoj Tandon: Fantastic. Well, Eric, thank you so much for being a guest here. We look forward to having you back at some point.

Don’t be a stranger as things develop; you’re more than welcome to come back and tell us a little bit more. We’ve only scratched the surface on this topic.

Eric Allard: I’ve done a few of these, and you are a number-one interviewer. It was great, very well done, and I’m happy to be on.

Manoj Tandon: Well, the honor’s all ours. Thank you. Thank you so much.