How to secure git

How to secure git

How can I make git more secure?

Git is super powerful.  We use git to interact with our most important intellectual property:  our source code.  For a SaaS provider this source code really is the whole business. If someone steals it, your IP is gone and so, probably too is your business.  So this begs the question:  How do you secure your use of git?

Git was originally written by Linus Torvalds to use for the development of the Linux kernel, and most engineers that use it only use like 1% of it:  git clones, pulls, pushes, checkouts, and commits.

I use git for many reasons now:  First, for the ability to automatically create a local (and centralized!) backup of what I’m working on (git commit, git push).  Second, for the ability to share my work with the team and let them iterate on the code themselves independently (git clone, git pull).  And finally, for the ability to fall back to an earlier version of a thing I was working on (git commit, git checkout).

I use git every day to work with my team of software engineers to build SecureStack products.  I also use git when I interact with open-source projects like MVSP.   Part of the power of git is you can use it for basically anything:   source code, text files, binary files, zip files, DLLs and a whole more.   So a lot of people end up using it as a backup tool, which isn’t really what it was intended to do.  This can cause problems later on and I’ve seen this first hand with customers of ours.

Unfortunately, there are definitely some gotchas that I learned along the way, that I am going to share with you now.  Enjoy!

1. Create a .gitignore file

As you are working on code you will want to make sure that your changes are being tracked.  The first step in doing this is to use a git add . command.   When you use the period as a wildcard you add anything in the working directory to that git repository.  And this is where many engineers create problems for themselves, without even knowing it!  Perhaps you had a .env file in that local directory that included all the usernames and passwords and connection strings for your app.  When you do your git add . you are adding that .env file to the repository, or any other config files that include sensitive data in them.

And it’s not just about making sure that sensitive data doesn’t get committed to your repository, it’s also about saving space and lots of time.  As an example, when working with javascript code it’s really common to add the whole ./node_modules directory into the repository.  Same with the package-lock.json.  These files and directories are NOT necessary and don’t need to be included in the repo.  When you do a npm build or run yarn these files will get created at build time so you don’t have to add them.

Create a local .gitignore file and add the appropriate exclusions there. You can get a list of customized exclusions from

2. Don’t store secrets in git repos

All developers have at some time thought it was perfectly acceptable to store credentials in a .env or config file.  It’s just something you do because no one tells you not to, and no one shows you a better way to do it.  And, to be fair it’s definitely a lot more complicated to use a secret store or key store to hold your sensitive credentials and application config details, than it is to simply put them in a local file and source that file.  But then at some point all developers will accidentally add that file to a gir repo and push to a centralized location and then the credentials go out with it and are distributed to everyone that pulls or looks at that code.  Then when the team finally notices and understands the problem, they have to go *fix* the problem!  That means changing the credentials (hopefully!) but beyond that it means that the team as a group has to do agree a solution and then follow through and use something like a secret store.
Truth is that many teams don’t realize how easy this can be.

3. Use git hooks to automate tests

Most developers don’t realize that every git repo comes with a pre-configured set of git “hooks” that allow them to automate parts of their continuous integration workflows.  If you look in the .git/hooks/ directory of your git repo you’ll see 12 files by default.  Of those, the most powerful and best one to use for this purpose is the pre-commit git hook.  These git hooks are just scripts so you can drop bash commands right in.  Create a new file in that directory called “pre-commit”, make sure its got execute permissions and drop your security tests directly in!

You can read more in our blog post about git hooks here.


4. Use SSH keys to interact with repos

Most companies use their company email as the login to their source code management platform like GitHub or Bitbucket.  Then, to make it worse, most orgs don’t enforce using MFA or the use of SSH keys, so now all the bad guys have to do is phish your engineers and get their passwords and your crown jewels are now in the hands of criminals.  So, the easy fix is to enforce the use of MFA and/or SSH keys during login.  Why?  Because this verifies that the user is who they say they are with at least one additional factor of authentication.  I would suggest you use SSH AND MFA with something like Krypt.  Some organizations only require occasional multi factors, like every 30 days or similar, but to me, it makes sense to have the power of multiple factors with every push.


5. Upgrade your git!

Many developers using a mac don’t realize that the version of git they are using is probably old.  Most git installs on Apple devices come from the Xcode package and typically are two or more years old.  For example, until I installed git from brew I was using the most recent version of git via Xcode which was 2.24.3 which can out in late 2019!

You can find the most recent version of git at

get latest version of git

6. Don’t make stuff public that shouldn’t be

Most of the git repos we find sensitive data in are set as publicly accessible, and they shouldn’t have been.  This one is easy to do especially with GitHub where the default behavior for new repos is different depending on whether you are in an “Organization” or not.  The default is to create new repos as private if you are in an org.   But if you are creating a repo in your own account, the default is still public.  Doh!

If you *are* going to create a public repo make sure you can ensure that no sensitive data will go into that repo.  Often, what a repository starts out as isn’t what it ends up as.

github default is public

7. Don’t upload your .git directory with your web content

Many developers deploy website changes or content via git.  We did this for years when we built our website with static HTML and we could simply commit changes to a git repository.  Unfortunately, many people that do this don’t realize they are exposing their .git directory and all its contents with each deployment.   If your webserver allows directory listing then anyone that goes to will be able to see all of the git contents including the config file.  The URL for your git repo will be in that file and anyone that is handy with git will be able to download your git repo and dredge it for username/password credentials, database names or any other sensitive data you’ve saved in the past.


Many developers I’ve talked to about this problem push back saying that  you can’t get much with a git repo and to them I say, look what I found today:



That is a customer’s production database creds sitting in a .env file in their exposed .git directory.  I wonder what they could do with that?!


SecureStack provides security coverage across the whole of your SDLC

Our platform helps you protect your most valuable asset:  Your source code.

SecureStack is easy to use as it’s a SaaS-based platform so you can be up and running in less than 3 minutes with complete coverage.


If you like what you see, book a demo!


Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!


What is a SBOM?

What is a SBOM?

One of my friends messaged me on LinkedIn today and asked “What is this SBOM you keep talking about?”  I realized that he’s right and I should probably explain what an SBOM is.  First, the term refers to a “Software Bill of Materials”.  An SBOM is a complete inventory of all the software and dependencies of an application and is typically delivered in the form of a JSON or XML document.  Why is an SBOM critical?  Well, one reason is that they provide visibility into the software supply chain behind a particular application.  It also helps teams test an application for compliance and identify security risks that an app might have.

Wikipedia defines an SBOM this way:
“A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product.  It is analogous to a list of ingredients on food packaging: where you might consult a label to avoid foods that may cause allergies, SBOMs can help organizations or persons avoid consumption of software that could harm them.”

Why is everybody talking about SBOM now?

The need for something like an SBOM specification has existed for many years but has become more visible in the last two years as several top several high-profile security incidents. In particular, the SolarWinds incident in early 2020 as well as ongoing issues with NPM have made it obvious that there needed to be more governance around the software supply chain than there was.

Applications have become increasingly complex which in turn makes securing and managing those applications more difficult. Cloud-native services and open source make up a growing part of the average modern web application. Software engineering teams don’t necessarily understand how adopting these new technologies or services changes the threat model for their applications. The SBOM is meant, in part, to at least make these components visible to the naked eye so teams can understand the scope and breadth of their applications

The Biden administration passed an executive order in 2021 entitled “The Executive Order on Improving the Nations Cybersecurity”. This executive order requires that any companies wishing to sell to the US government must meet SBOM requirements.

What’s in an SBOM?

At its simplest a SBOM is a list of all the different component parts of an application. This typically includes several types of information about each component:

  • Component name
  • Supplier or vendor of component
  • Software license type
  • Component version number
  • Known vulnerabilities for component
  • Transitive dependencies to other software

Defining these core data points about each application composition object means that engineering teams are in a better place to be able to mitigate or remediate issues in these components. Tracking this information over time means that a properly built SBOM will catch and make visible any changes that can adversely affect the application.


How do you create a SBOM?

Because there are several different formats for SBOMs organizations will need to make a decision which they will support internally. Or, alternatively, they will need to have the right data in place to create any format they are asked for.

Unfortunately, there is no consensus on what a SBOM should look like or include. There are LOTS of suggestions, and vendors describing their way as the only way to create and handle SBOMs. The reality is that there are at least 3 different formats for SBOMs:

If you like what you see, book a demo!


Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!


DevSecOps predictions for 2022

DevSecOps predictions for 2022

2021 was a CRAZY year!

We spent most of 2021 at home.  We had to build new ways of working and migrate things to the cloud WAYYY too quickly.  We saw new types of threats to our applications including “dependency confusion attacks” and “software supply chain attacks”.  We began to question all our dependencies and vendors.  Who are you, and what are you made of?!  We saw outages increase for Azure, AWS, GitHub and Atlassian.   And, we finished it off with arguably the GOAT vulnerability:  Log4shell.  What a crazy f**king year, right?!

It’s now time to turn our attention to the new year and I thought I would crack a tasty beverage and wax prolific on what I see coming for the DevSecops and AppSec communities for 2022.  As always, I appreciate your feedback so feel free to hit me up in the comments below or ping me on the socials.

1. “Software Bill of Materials” (SBOM) is everywhere! 

Every American we talk to whether they are in venture capital, startups or enterprise is asking us if we can provide SBOM capabilities. Australians are beginning to become aware of the idea as well via our five eyes osmosis.   The impetus behind this all are a new set of requirements set down by the Biden administration in 2021 that enforce SBOM standards on orgs trying to sell into US government. My first prediction for 2022 is that SBOM will evolve to become “Application Composition Graph” as the idea of SBOM expands to include the non-source code dependencies in applications. Think AWS Cognito, Cloudflare Workers, API Gateways, Lambda, Azure Functions, Firebase, etc. If you take any of those services out of an application that uses them, that app stops working.  If the app can’t live without something, then that’s a primitive dependency. Therefore, these dependencies need to be expressed in the same way that a node or python library does. Like many standards, the people defining the standards often don’t understand how the underlying controls or requirements are enforced. As an example of this the current SBOM standards and formats like CycloneDX only really work with software package files. They will have to evolve to provide SBOM features for cloud infra, SaaS tooling, CI/CD processes and more as these components are just as required as the underlying source code. This new “enhanced” SBOM complexity absolutely screams out for a graph to express those complicated back and forth relationships between dependencies. However, you will always need to provide for it in something easy to undestand for machines so this means that whatever “graph” like representation we use, this new SBOM will have to be able to be represented in JSON or YAML. At SecureStack we have been using an internal description of an application called a WHAM since April 2020. This WHAM stands for “workload hierarchy abstraction model” and is really about understanding how data enters an application and what it touches. For example, the CDN, loadbalancer, webserver, appserver, app and database are all listed in order and their individual dependencies and relationshipos are defined. This is similar to SBOM and makes it easy for us to map to the new SBOM requirements. Checkout my teams thoughts on SBOM here:

2. CI/CD Visibility

The theme from 2021 was: how do we modernize the software delivery process because we all might be working from home for a while? The ability to focus on modernization was made possible by the fact that everybody was at home and the company VPN and infrastructure was not always capable of enabling or satisfying the needs of software engineering teams. So this created a forcing function to move to cloud-based SCM like GitHub and Bitbucket as well as cloud-based continuous deployment platforms like CircleCI. Stuck at home, engineering teams had time to finally build out automation that we had been talking about for years, enabled by the ease of the new cloud SCM vendors. At SecureStack, we saw this a lot as legacy enterprise customers suddenly started using Bitbucket Cloud and GitHub because there were too many obstacles to them using their existing legacy SCM solutions. But now, in 2022, these orgs have moved successfully to the cloud and are building their first production-quality continuous delivery models, they need to focus on gaining more visibility into all this new “stuff” so management will continue to give them the green light. And the budgets. Salivating startups seeing new market opportunities will build visibility platforms to compete with native functions from GitHub, Bitbucket, and all the other platforms. Up until now different parts of the #devtools space have been pretty siloed. Different focuses like “code quality”, “code security”, “application performance”, “dev collaboration”, “api functionality” and “developer insights” will come together in explosions of tooling to join existing continuous deployment solutions to create richer ways to define maturity and progress for engineering groups and their managers. All of this brings us to….

3. CI/CD is the new Supply Chain attack target

In 2021 we saw attacks targeting npm libraries like ua-parser-js as well as dependency confusion attacks targeting Microsoft and malicious code found its way into the Linux kernel. This got me thinking about my own continuous deployment pipelines and how we use third-party software in those pipelines. And that got me thinking specifically about GitHub Actions and Bitbucket Pipelines. These two technologies run pieces of automation in your continuous integration and deployment processes and many orgs rely on third-party providers to deliver these stackable pieces of automation. And here’s the thing: These Actions and Pipelines have complete unmitigated access to your source code during the CD processes. During the testing and build phases for all your continuous deployment vendors spin up temporary transient containers to test your code and do “stuff”. Some of that stuff involves security testing or functional testing. There are thousands of these automations out there and many orgs use these functions without really understanding what they are doing. Imagine if someone got access to one of these popular Actions and inserted a single line of code that sent your source code to an S3 bucket. Whoops, your intellectual property just got sent to China! Or maybe it added a line to your source code to use a new dependency that was malicious? There are a million things that a bad guy could do with this super powerful moment in time. Most of the GitHub Actions for example are maintained by small teams of volunteer contributors. How many of them use MFA and/or SSH keys to interact with GitHub? How many of them are using EDR on their laptops to make sure that someone isn’t manipulating files on their local repositories?! It’s really hard to define security standards for a group of people who are volunteering their time. So just like with the NPM dependency shit show, the GitHub Actions and Bitbucket PIpelines and similar are places we need to start looking and thinking about how do we secure these new tools?


4. DevSecOps hype-cycle will hit escape velocity

Every vendor will claim to be a “DevSecOps” solution. In 2022 we will see XDR, EDR, CSPM, and other solution providers start marketing in this space claiming to be the “missing piece of the DevSecOps puzzle”. It will get totally non-sensical over the next year. Tools that have no business in the continuous deployment process, will build GitHub Actions and start advertising how they are an integral part of your continuous deployments. Non-technical managers who are easily swayed by big names will not be able to discern what is legit and what isn’t, which is the whole point of this marketing frenzy. Technical people will be forced to add Actions and Pipelines that just make their deployments even slower and make them start building rogue CI/CD solutions.


5. Software Composition Analysis hits a snag

Traditional software composition analysis (SCA) solutions will stagnate as development teams realize how little value they provide in isolation. This is one reason that Snyk is acquiring startups left, right and center. For example, NPM has had built-in SCA functionality via its npm audit since 2018 and moreover, npm audit messages have been shown by default during every npm action since npm 6. Unfortunately, pretty much every developer and really the whole javascript community ignores these messages every day. Engineers simply ignore these messages, both on their laptops and in their continuous deployment processes.


6. Semgrep will be acquired

Or more correctly, the company behind the amazing Semgrep tool, R2C will be acquired. Semgrep is just too good to not get gobbled up for hundreds of millions of dollars. It probably won’t be Microsoft because they (well, GitHub actually) already bought Semmle in 2019. And it probably won’t be AWS because they keep thinking they can compete with their Code* products and so far they haven’t shown any interest in acquiring in this space. Snyk bought Deepcode in 2020 but I think the bigger blocker here is that Snyk doesn’t target a community, while that’s exactly what Semgrep is all about. So who does that leave? Google? Cloudflare? My pick might seem like an odd one, but I’m gonna say IBM. Or, actually, the new MSP part of IBM that has been spun off on the NYSE: Kyndryl. Kyndryl has cash on hand (via IBM debt) and they desperately want to get into the DevSecOps play as a way to build out both their services business AND their product line.


7. Palo Alto will buy a #devtools startup

Why not? PAN is trying to build an end-to-end platform, so why not throw some code security tooling under the umbrella? There are a bunch of players out there to buy.  Aqua already bought up so you can mark them off the list but you still have Oxeye, Cycode, Cobalt,


8. Java will become persona non grata

In light of the recent log4shell shit show and its never-ending patching requirements, many in the industry have started saying openly that we need to get rid of Java, permanently. Like, the Godfather and the cannoli permanently. This technology is old, is SLOOOWWW, and has too much attack surface. There is so much XSS, CSRF Advertising a JSESSIONID: cookie is now a liability and the attack traffic you will have to block at your edge has now become one of your teams full-time jobs as they manage traditional firewall and WAF rules to address the never-ending onslaught. Not to mention that we’ve basically forgotten as a culture how to install a JDK or JRE on our laptops which kind of says it all, right? In a post-Java world, just imagine the cost savings in no more WebSphere, JBOSS, or WebLogic, or Liferay licensing! Java was great back in the day, but it’s not worth the hassle now.


9. AWS will give up on its internal Code * services

AWS has a series of software development solutions all starting with Code: CodeStar, CodePipeline, CodeDeploy, CodeBuild, CodeCommit and CodeArtefact. No one uses these tools unless they are clueless or complete AWS fanboys. Don’t get me wrong, we love AWS but AWS can’t be everything to everyone. I know that’s their play, but I can’t help but think of the amount of energy and time they are wasting internally to make all these Code* solutions get traction. The reality is the market is set and other vendors outside of AWS do this whole software development lifecycle stuff much better. Every software engineer (aside from fanboys) understands this, but when is AWS gonna finally admit they can’t do everything?

10. CEOs will start going to jail for hiding data breaches



11. Everything will become “critical infrastructure”




Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!


Security uplift for your startup or SMB company

Security uplift for your startup or SMB company

Small and medium businesses (SMB) account for 97% of all businesses domestically and employee 68% of Australians. SMBs are usually described as less than 50 employees, with $10Million of annual turnover or less.

This large part of our economy is not well suited for many of the sophisticated cyber attacks that now exist. They usually don’t have any IT employees and instead outsource the IT administration to Managed Service Providers (MSP) or IT consultancies. These same small businesses are the hardest hit by cybersecurity issues with 60% of SMB companies going out of business within 6 months of a cyber attack or data breach. They just don’t have the resources to fight and then contain a cyber event. They’re rarely prepared for the brand damage that will come from it and eventually stop trading. This is particularily true for ransomware attacks as often the important data can never be recovered. Imagine if this is your list of clients? Or your intellectual property? Or if you’re a graphic designer and all your images were suddenly unusable. You can see how this could kill some companies.

I saw this first hand as an IT consultant for many years. Before a breach customers would often say that it wasn’t worth paying the money to address existing security issues. This is common as SMBs typically don’t like paying for cybersecurity but are the hardest hit when it eventually happens. This paradox is not sustainable and we need to find inexpensive ways for SMBs and startups to uplift their cybersecurity.

This is even more important in a post COVID-19 world. Teams were moved to work from home (WFH) quickly and many smaller companies didn’t have time to sufficiently prepare for the cybersecurity challenges that this new world presents. I started writing this several months back, but this is a perfect time for me to publish.

So, here’s my list in a roughly prioritised fashion. The emphasis is on simple security that non-technical people can use. These first eight controls (1-8) are implemented on the employees individual computer, or phone (or both). Numbers 7 and 8 need to happen on employee computers, phones AND any servers (physical or virtual) that the company owns.

1. Multi-Factor Authentication

Before you do anything else install a multi-factor authentication (MFA) app on your smart phone if you don’t have one installed now. Then have all your employees do the same thing. I prefer Authy, but the Google Authenticator application is probably the most common. Being a Michigan boy, I have to mention the Duo Mobile MFA tool can be found here. Microsoft has their own app as well. Authy allows you to do backups and migrate to a new phone and a lot of other housekeeping functions that the others don’t. There is still room for improvement with these apps as I personally would like to see the ability to create folders within the tool to manage similar types of access as well as biometric access to the app. However, the price is right.

Next: Make sure that all important websites you and your teams use have MFA enabled. Banking, Xero, LastPass, Jira, Bitbucket, Github, O365, AWS, Azure, etc. Then once you are done with your web apps, do the same thing on your phone apps: Banking, Rewards accounts and any other apps that are important to you and that you need for work. If it supports MFA, enable it and use your authenticator from #1 above. This function alone can save your ass more than anything else when you are being targeted.

You can check if your bank or other common websites support MFA here:

Lemme vent about one of my pet peeves here: I don’t know why Australian banks have lagged so far behind on adding support for MFA apps to their web portals. NAB and CommBank both do NOT have MFA apps as an option on their web apps. CommBank will use a “NetCode” which is delivered in their app, but that’s only if you are authorizing a new payment or BillPay. What are you providing CommBank to protect my login to your NetBank and Web portal? CommBank, please up your game and offer support for MFA apps for customers that want to use it!

Cost: FREE

2. Password Manager

Install a password manager and then configure it to use multi-factor authentication (MFA) using the MFA you installed in #1 above. I personally use LastPass, but I’ve heard good things about both 1password and Dashlane from friends of mine. Whichever tool you use, make sure that the master user and password are protected by MFA. MFA and a password manager are the two best things that a user can do to protect themselves. If you have employees I highly recommend you upgrade to the paid version of whatever tool you choose. You can then give each employee their own set of credentials and delegate required access.

  1. LastPass:
  2. 1password:
  3. Dashlane:

Cost: FREE

3. Security Browser Extensions

Do NOT use the browser that came with your computer and definitely don’t use a browser in its default implementation. Securing the browser means using extensions to protect yourself.

I recently wrote a blog article about the security and privacy browser extensions that I use. And, they’re all FREE!

Cost: FREE

4. Endpoint Protection (AV/EPP/EDR)

Back in the day I used free anti-virus tools like AVG and MalwareBytes and it was good enough. That’s not the case anymore. I can’t in good conscience suggest people do that in 2020. The threat landscape has changed too much, and for the worse. Instead, I recommend that you invest in a good “Endpoint Protection” (EDR) solution. I am personally using BitDefender myself but am contemplating on changing as BitDefender is refusing to let me pay for an upgrade in subscription. Regardless, most EDR solutions have a central management console that allows you to see and manage all computers you are managing with their platform. This is important as you want to make sure that all employees devices are up to date and have latest virus signatures, etc.

Whatever you do, make sure you get something with some ransomware protection built in. In fact, this probably needs to be another blog post about how to protect yourself from ransomware attacks. Stay tuned…

Cost: Starts at roughly $100 per employee per year.

5. Add Anti-Virus to Your Browser

Now that you have your EDR solutions sorted from #4 above, make sure that you have an antivirus web extension installed and turned on for your browser of choice (or all browsers really). Good products like BitDefender will automatically install this for you.

Cost: FREE (well, comes with paid subscription)

6. Sync Browser Data

I suggest you add the free sync feature in Firefox or Chrome. These functions mean you need to create an account with Chrome or Firefox but then any time you log into Chrome on any computer you will get the same bookmarks, history and cookies.


And Firefox:

This is very helpful but is definitely a potential privacy concern. I’ve wrestled with this dilemma internally and have decided that the security and redundancy that having Google back up my stuff outweighs my personal privacy concerns. You can read about setting up Google sync here.

Cost: FREE

7. Backups

Setup backups for any important systems. This includes laptops and workstations, not just servers. Many companies think that because most of their business functions happen in SaaS applications that they don’t need to do backups anymore but my question then is, “how long would it take you to setup your laptop again to 100% working?” and “how long would it take to perform 100% of your business functions on a brand new laptop?”

CrashPlan, Carbonite, Backblaze and other online backups have cheap pricing for SMBs. I have personally used CrashPlan for years and have used it several times to restore family, friends and clients data after it was encrypted with ransomware.

One last minute addendum here: If you have a Mac I would recommend you use Time Machine. It’s simple and free but make sure you backup to a separate device at least once a week. Do not rely on a USB drive that’s always plugged in. If all your files are encrypted in a ransomware attack, that USB disk will be encrypted as well. So, pay for a couple 500G or 1TB drives and swap them once or twice a week. This article does a good job of explaining it.

Cost: FREE. Paid backup starts at $10 a month per computer

8. Update Software

Software on your individual computer needs to be updated at least once a month, and preferably much more often. This applies to your desktop computers, mobile devices and any servers that you own or run. This is often a problem for that on-premise server that has been sitting in the corner for years serving up your files. When’s the last time it was patched?

If you aren’t patching, you are leaving yourself open to a host of potential threats and attacks. It’s similar to not getting vaccinated for diseases that you could easily protect yourself from. Set a day at least once a month, when you update and patch all your devices and services. Then block time for all your employees to actually do it.

Cost: FREE

9. Link Awareness

Be very careful about clicking on any links in an email, PDF, webpage or similar. See those links above? They look harmless, right? If you hover your cursor over them, and wait a second, the link will display what it’s going to. Train your staff to look and read the domain before they click. Clicking on unknown links is the origin of most ransomware and cyber attacks. Even worse, criminals have learned to register copycat domain names like and which look legit at first glance, but send you to a copycat website. That fake site collects your real credentials and then sends you on the real website where you log in successfully not realizing what’s happened.

Consider applying other controls like endpoint protection or email filtering to limit the possibility of your employees clicking on the wrong link.

Cost: FREE

10. Cynch

Buy a Cynch membership. Cynch is the only cyber fitness platform designed for small business. They take the complicated technical jargon out and replace it with common sense plain language. Cynch helps small business define, quantify and address their cybersecurity related risk. Cynch is as little as $99 a month and it helps your whole team become smarter about cybersecurity while it protects your business.

These guys are friends of mine and are making a great difference here in Australia:

Cost: Starts at $99 a month

11. Phishing Awareness

If you don’t buy a Cynch membership, then at least buy some phishing training. There are cheap courses online in places like Udemy. I suggest you pay for something decent as phishing is one of the most successful ways that Australian businesses get scammed. The city of Brisbane alone has lost over $600k in multiple schemes this way. The phishing attacks have only grown in sophistication and are now coming from within Australia, so the person on the other end of the phone or email sounds like you and knows the same things that you do because they’ve studied your company and done their research. Potentially FREE, but you get what you pay for?

Cost: Varies, and some resources are FREE

12. Wifi Isolation

If your employees or guests can bring in their own computers, tablets, or connect their smart phones and connect to your company network, this is called “bring your own” or BYO.

Have your IT team create a second wifi network for them called “Guest network”. Next, create complex but understandable passwords for both the guest and “Work” networks and be prepared to rotate them once a month at least. I know this is a pain in the ass but it protects you as all your neighbours will eventually get the password and if you don’t change it they will be living off your internet connection for YEARS. Finally, make sure none of your employees are violating this policy and make sure that all BYO devices are NOT on your work network. Your IT team can use some relatively simple methods to add only work computers to the work wifi (mac addresses bound to DHCP leases is a good example).

Understand that your internet connection is your responsibility. If someone uses it for illegal activity you could be liable.

Cost: FREE

13. SaaS Management

SMB companies use a lot of SaaS software. SaaS stands for “Software-as-a-Service” and describes software that you use through a browser that doesn’t need to be installed on your computer per se. How many SaaS applications does your company use? Common SaaS apps for SMBs are: Xero, MYOB, QuickBooks Online, Google Mail, Microsoft Office 365, Wix, and SquareSpace. Some common startup SaaS apps are: Mailchimp, Hubspot, Slack, Asana, Github, Bitbucket, Calendly, Basecamp, Airtable, Google Docs, Microsoft Office365, Sketch, Trello, Jira, Canva, and Pipedrive. There are obviously hundreds more that SMB customers use. SMB companies with less than 20 employees average at least 26 different apps in use. Startups often use an average of 100 or more SaaS applications.

Managing the logins, credentials, permissions, etc can be a real headache for people. Especially if you don’t have a dedicated IT person to handle it all. This is a real issue for many companies as they don’t keep track of the logins and credentials and then have to constantly reset the passwords for these SaaS tools. This ongoing behaviour makes it hard to catch a bad guy who does something similar. The email telling you about the password change (by the bad guy) gets lost in all the other legitimate password resets.

It’s important to define the SaaS assets and credentials that your company requires and use separate complex passwords for each SaaS app. Add all those logins to your password management tool from step 2 above and make sure that you protect that master account with a great password and a MFA app from step 1.

Once that’s all done make sure you add more than one person to the master account so if that person leaves or gets hit by a bus you have a backup admin that can retrieve those credentials.

Cost: FREE

14. Hire a Pro

If you are going to host a web application, interact with customers online, sell online or use the web as a primary means to conduct business, you should hire a pro to make sure that you do all that safely. If the loss of something like email, your website, chat functions or similar would damage you financially, then it’s time to budget for a cyber uplift. It’s surprising to me how undervalued cybersecurity is by many SMBs until they have a security incident and then the reality sets in that maybe they should have done more. Cyber attacks and data breaches are particularly disastrous for SMBs, so take the time to follow the steps above and then hire a pro.

If you need help with managing your on-premise or SaaS applications, we can point you towards one of our MSP partners. If you need help building or designing a web application or functionality in the cloud, we can point you towards one of our solutions provider partners.

If you need help scaling or securing your web application we can help you out:

Cost: Well worth it

I hope you’ve found something useful in this that will make your small business stronger and more resilient. If you think I should add something please hit me up here.

Cybersecurity firm and multiple US government departments hacked.

Cybersecurity firm and multiple US government departments hacked.

When one of the most advanced cybersecurity outfits in the world AND the US Government get owned, what chance do YOUR apps stand against hackers?

The US Government has issued an emergency directive to power down SolarWinds Orion IT management tools after identifying a major security breach where infected updates have been used to compromise the networks of multiple private and public organisations. SolarWinds’ products and services monitor the health and IT networks and are used by more than 300,000 customers worldwide, including military, Fortune 500 companies, government agencies, and education institutions.

The Cybersecurity and Infrastructure Security Agency (CISA) has advised customers to “treat all hosts monitored by the SolarWinds Orion monitoring software as compromised by threat actors and assume that further persistence mechanisms have been deployed.”

As a result of this shocking attack, high profile cybersecurity firm FireEye last week saw hackers breach its network and gain access to some of FireEye’s internal systems, stealing the toolkit used to probe customers’ systems to find weaknesses. FireEye’s stock has now plummeted 10.9% to the lowest levels the company has traded since last year and the FBI is now investigating the attack.

These worrying events mark the first time in many years powerful hacking tools have landed in the hands of adversaries, with experts saying the incidents may be just the first of many…

Which begs the question, what chance do YOU stand against hackers?

That’s where Bloodhound comes in.

Want to see what a hacker sees when they view your app, and how to fix it?


Bloodhound sniffs out security gaps and throws you a bone teaching you how to fix them. The best thing is that in beta stage, it’s also 100% FREE.

The Top 20 Cybersecurity Startups to Watch… Featuring SecureStack!

The Top 20 Cybersecurity Startups to Watch… Featuring SecureStack!

Did you hear? This week we were named by Forbes as one of the top 20 cybersecurity startups to watch in 2021!

As the only startup on the list helping developers find security and scalability gaps in their web apps, we are extremely humbled and excited for the incredible recognition.

Our commitment to you, developers, in 2021 and beyond, is to offer more ways to fix those security and scalability gaps without you needing to become security experts.

Check out the full article here and gear up for a big year ahead!

Meet your new best friend: Security scanner and solution finder, Bloodhound by SecureStack.

Made by developers for developers

We democratise access to security scanning but this is just a starting point—scanning alone does not solve security problems. Another product that allows you to throw problems over the fence to a siloed team will have no impact. 58% of security alerts are being neglected. (Do you believe that? 58%.) We facilitate smart and efficient remediation by not only flagging what needs to be fixed, but how to fix it. We prioritise action over reporting and security over compliance.

App security is complex, but that doesn’t mean the solution can’t be simple

We present code, infrastructure and tooling solutions that any developer can apply without having to be a security expert.

We facilitate building better applications by helping customers understand the many disparate components that make up their application, and giving them ways to embed security and scalability across it all. We provide solutions that are repeatable and automated at scale.

It’s all of our responsibility to get security right. We at SecureStack make getting security right easy.