Code Signing Best Practices
Want to keep your software and code safe?
Enter your contact information below below to receive your FREE Best Practices PDF:
On average, developers spend up to 42% of their time dealing with technical debt. That’s a major productivity loss. This trade-off between releasing new products fast and creating secure and high-quality software is estimated to cost organizations a whopping $5 trillion within the next ten years.
And while some degree of technical debt is unavoidable in the real world, when it gets out of hand, the consequences can be severe. Knowing and understanding the causes of technical debt, particularly with regard to software security, will help you find and implement the right solutions.
Join us on our journey that explores the underlying, multifaceted causes of technical debt, its symptoms, and how to deal with the causes from a security perspective.
Technical debt, sometimes called tech debt, is the proverbial elephant in the developers’ room that no one wants to talk about. It’s a bit like the black sheep of the family that no one wants around, and every time its name is mentioned, all eyes roll.
Why? Let’s explain it with an example. Does your organization continue using legacy software because it supports critical applications or systems? You all know that it should be replaced, but no one dares to touch it. Why? Because swapping it out will be one nightmare of a job. Some crucial operations may have to stand still for a few hours. That’s tech debt. And that’s why people often want to run out of the room as soon as it’s mentioned.
But teams keep on delivering codes faster than lighting. The monotonous and often time-consuming (yet important) stuff (e.g., patching vulnerabilities, bugs, and addressing security issues) gets postponed until “later.” And when “later” never comes, the elephant (i.e., technical debt) gets fatter and more burdensome.
Want to exit this vicious cycle? To do that, you’ll have to figure out the real causes of technical debt first. Because as the English poet John Dryden once said: “The best way to solve a problem is to remove its cause.”
Are you drowning in tech debt and don’t have the time to read through the whole article? We’ve got you covered. Here’s a quick summary of the most common causes and solutions in our table below.
|Causes of Technical Debt||Solutions|
|1. Developer Shortages and/or Increased Workloads||
|2. Tight Deadlines and Budgets||
|3. Lack of Expertise/Skills||
|4. Lack of Coordination and/or Collaboration||
|5. Poor or No Documented Standards||
|6. Inadequate or No Testing Procedures||
|7. Overly Complex Code||
|8. Unexpected Technical Issues and Requirement Changes||
|9. Relegating Security to the End of the Development Cycle||
|10. No End-of-Service Life Cycle Process||
|11. Rapidly Evolving Technology||
Want to get the most out of this article? Then keep reading.
Software developers have been highly sought after in the past several years, much like the latest smartphone model. According to a recent CoderPad survey, they’re the most in-demand technical roles in 2023, with back-end developers at the top of the rankings (55.04%).
But the demand is higher than the supply. Organizations are struggling to fill vacant positions, and 4 million developer jobs may still be unfulfilled by 2025. And what do you do when your boss wants you to deliver the new application “yesterday” and you’ve only two developers working on it?
Their workload would increase disproportionately, and since they aren’t octopuses with multiple tentacles, you’ll inevitably have to cut corners. As a result, they may:
Over time, all the problems caused by these wrong, rushed choices will accumulate. They’ll become increasingly difficult and expensive to fix the longer you wait.
I know that asking your boss for additional resources is like asking uncle Scrooge for a $100 bill. So, let’s assume you have to make do with the resources you have. How can you avoid accumulating too much nasty tech debt without killing your two developers or seeing them resign because the project gobbled up their personal life?
51% of organizations are planning to increase their IT budget in 2023, according to data from SpiceWorks Ziff Davis (SWZD). Don’t start celebrating yet, though, as 51% of them will invest that money to upgrade their infrastructure. Are you lucky enough to have the right number of developers on your team but still struggle because of tight deadlines and a limited budget?
Rushing your project because your boss said so is never a good idea, but often development teams do so to keep the management happy. I always remember a phrase one of my colleagues told me on the first day at one of the companies I worked for: “If your manager asks you to jump out of the window, you do so. He’s your boss.” And I also remember very well what I thought: “Hell, no.”
Working a bit under pressure is OK; it can even be motivating. But when the pressure reaches a tipping point and becomes too much, all you’ll get are mediocre results and frustrated, burned-out team members. And when they’re tired, mistakes are just around the corner, fattening up that elephant in the room.
Developing an application with strict budget constraints and tight deadlines is a bit like trying to build a two-story house with a patio using only wood and a hammer. To respect the agreed timeframe, you’ll eventually reduce the number of floors to one, scrap the patio, and cut down the number of windows. You’ve still built a house, but not as sturdy as you planned, and many features are still missing. This is another example of tech debt.
In addition to the solutions listed in the previous point, there are other things you can do to limit or even avoid feeding your tech debt monster.
According to Manpower, nearly four out of five employers struggle to find candidates with the right skills. Fullstack developers are most wanted but also the hardest to find; they’re followed by front-end and back-end developers.
You can’t find a back-end developer? You can get away with using a full-stack one, but you may have to compromise on programming languages. You aren’t so fussy? Beware. Choosing the wrong language may further impact the quality, flexibility, and maintainability of the application you’re creating.
Last but not least, inexperienced developers may add another heavy brick to your tech debt wall. How? By implementing improper solutions when they don’t have anyone to point them in the right direction.
Experience and technical skills are like Rome: they can’t be built in a day. Mastering a programming language or learning a new skill — even an “easy” one — takes time. How can you ensure your tech debt doesn’t inflate because your employees don’t have the right skills?
You have no idea how much poor communication and collaboration can negatively affect your technical debt until you’ve experienced it. I discovered it at my own expense, and it wasn’t pleasant.
At the time, the product and the developer teams sat in different offices on the same floor. This shouldn’t have been a problem, as it was just a short walk, and communication between the two teams would be a given, you’d think… Wrong.
Yup, despite the two teams being only a few steps away from each other, the collaboration and communication between the two groups could have been a lot better. Even if you have a daily meeting and you’re using an Agile approach to manage your project, it didn’t matter; the collaboration and coordination just weren’t there. And it got worse over time as things became increasingly siloed. They were doing their things, and we were doing ours, without even minimal coordination.
As a result, misunderstandings, errors, and issues were often discovered too late in projects. Thus, these issues were often left unsolved or added to our technical debt to be dealt with “later” (there’s that word again). Did we find a way to put it right? We surely did, eventually, but not without first experiencing a lot of headaches and unnecessary issues.
Coordinating teams scattered all over the building or, even worse, dispersed in different countries can be a tough nut to crack. Dreaming of teams with a seamless collaboration?
When I worked as an application security analyst, among all the tools we had, there was one I hated working with. It was built by a developer ages ago to automate tedious but critical manual tasks, but it was buggy and incredibly slow. It was built in a hurry and, as often happens, the open issues were never fixed. Technical debt, anyone?
One day, the developer who built it left the company. A few weeks later, disaster struck. We received an urgent request but the tool wasn’t working. We were panicking.
The new developer checked the tool and broke the bad news: the code was so oddly written that, to him, it was like trying to decipher hieroglyphics. To exacerbate the problem, there was no documentation to turn to for solutions. The verdict? He would need weeks to even try to figure out how the tool worked, let alone (hopefully) find the bug.
So, what did we do? We completed the task manually to respect the deadline while the tool was scrapped and rebuilt from scratch. This time, following the agreed programming standards (i.e., the written guidelines and rules to comply with in the coding phase to ensure that the final product is fit for purpose), help documentation was included.
Want a code that is secure, reliable, and with technical debt as low as possible?
The latest Verizon DBIR report shows that 82% of breaches involve human errors, among other causes. How can you even hope to prevent those errors without having proper testing procedures? You can’t.
We’re humans; we all make mistakes. Some are small and unimportant, and others can be expensive and have catastrophic consequences. For example, sources attributed poor testing procedures as one of the causes of two commercial airliners crashing and killing 346 people in 2018. The manufacturer failed to test the behavior of the airplanes’ software in case of a sensor malfunction. Got it now why testing is a critical part of the SDLC?
Integration testing, unit testing, security testing, you name it. They all facilitate identifying issues or bugs. And they allow you to fix them on the spot, without adding to your technical debt burden.
Too often in software development, testing is relegated to the final steps of the process. And that isn’t good enough. Review your testing process and ascertain that:
Want to dig deeper and learn more about improving your testing procedures? Check the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and Institute of Electrical and Electronics Engineers Standards (IEEE) 29119-1:2022 document. And for those among you who are testing geeks, there’s even a testing competition.
Have you ever had to add a new feature or fix a bug in a complex code? It’s a nightmare and usually takes ages. If you’re tasked with finding the bug first, good luck with that! You’ll spend hours looking for something buried in thousands of irrelevant code elements.
Complex code is often the result of developers rushing to deliver a product, or their reckless use of open-source components that are often more difficult to manage and update. But it also happens when the developer adds a lot of ‘nice to have’ and redundant features just to make their software look sophisticated. Thus, they’ll neglect more important elements that may cause serious security issues and add to your technical debt.
We’ve already learned how implementing and following code standards can help reduce your tech debt and make your code more readable. Code complexity is another aspect that clearly impacts readability, as proven by research published by MDPI in 2023.
As Albert Einstein said, ”Any intelligent fool can make things bigger and more complex… it takes a touch of genius and a lot of courage to move in the opposite direction.” Want to be a genius? Then you may want to try the following:
You’re a few milestones away from completing your project when, suddenly, your boss comes to your desk and informs you that one of the requirements has changed. Uh oh — it’s one you fulfilled some time ago. This is every developer’s worst nightmare.
I love surprises, and I’ve always been very flexible in my job. But constant software requirements changes aren’t fun for anyone, above all when an iteration cycle is thrown into turmoil.
OK, requirements may change over time (e.g., due to regulation changes, and new vulnerabilities). You’ll certainly encounter technical issues during the development phases. However, if you haven’t planned resources and time to address those worst-case scenarios, your tech debt may go up in a flash.
Incorrect requirements and failing to assess technical concerns at the beginning of the project can easily add to your tech debt.
48% of organizations interviewed by Arctic Wolf consider ransomware and targeted threats as their top concern for 2023. 33% of ransomware attacks observed in 2022 by Truesec started with the exploration of one or more vulnerabilities in the affected systems.
Are you still considering security as an afterthought? That’s a dangerous move that won’t only add to your tech debt, but it’ll also expose your product, organization, and customer to serious security threats, including ransomware.
Do you ship vulnerable and unsigned codes to save time and money? It may look like the cheapest solution now, but it may cost you more in terms of remediation activities, lost sales, and decreased consumer trust in the long run when things go wrong (and they inevitably will).
Prove Your Software Is Trustworthy
Signing your code shows users that your software and updates can be trusted.
Download our free code signing best practices eBook to learn how to help keep your supply chain secure and your company, customers & end-users safe.
The latest Great eXpeltations annual report confirms that 2022 was a critical year for cyber security. According to the data, compromised ISO files were one of the new attack vectors counting for 12% of ransomware incidents, according to their data. To re-focus your SDLC on security and keep your tech debt on a tight rein:
Did you know that 93% of organizations surveyed in January 2023 are still using legacy applications? This is according to data from Harmony Healthcare IT. I bet you are using one or more legacy systems, too.
Why? Some companies find older systems easier to use, while others don’t dare touch critical components for fear of negatively impacting critical operations. Others simply don’t have the money or the time to invest in system migration. But sticking to an obsolete application without a proper deprecation plan will add another heavy weight onto your technical debt.
The same survey we just mentioned reported that 58% of CIOs managed to save significant funds by decommissioning legacy software. Get rid of the oldies. You may have to invest, but you can put your tech debt elephant on a diet by implementing the following:
Did you know that a Moso bamboo can grow up to 3.74 feet (1.14 meters) in a day? That’s super fast. And do you know what else is evolving at a rapid pace? Technology. In a short amount of time, we’ve seen existing technologies evolving into something greater and new, futuristic services and products hit the markets. Among them for example:
These are just a few examples of the novelties that are shaping our tomorrow. Keeping up with everything isn’t easy, above all when you’re developing software. Lag behind and you may end up releasing a product that’s obsolete before it’s out the door. The consequence? It’s elementary, my dear Watson: you’ll get a higher tech debt.
Want to avoid ever-changing technology having too much of a negative impact on your development project?
It’s clear now that technical debt is an inevitable part of software development. Like a house, no matter how well you construct it, it’ll need some renovation work (e.g., a new roof or windows) sooner or later. The same concept applies to your applications, which will need improvements and updates over time.
Want to manage your tech debt to ensure it won’t get out of hand? Here are three tips to follow:
Pro tip: Let your developers plan their time to tackle tech debt.
C’mon, it’s technical debt payback time!
The past few years of technological evolution have brought organizations incredible new solutions and leading-edge tools. These assets enable them to create wonderful, innovative products in a fraction of the time. But these perks came at a hidden cost represented by technical debt.
As you’ve learned, the root causes of software security-related technical debt can span the gamut from a simple lack of documentation to tight deadlines, or the more dangerous habit of waiting to consider security until the end of the project.
Now that you’re more than familiar with what’s causing the exponential growth of your software security-related technical debt, please don’t let it get to the point where you ignore it until disaster strikes. Instead:
Your customers will enjoy more secure and less buggy products. Your organization will become more competitive and have more money and time to invest in innovation.