As software engineers, we are incredibly busy. We’re designing new features, writing tests and implementing code, debugging, opening pull requests, and performing code reviews. That’s not to mention all of the DevOps stuff that our teams have us doing nowadays, too. Oh yes, and then there are stand-ups, check-ins, one-on-ones, and all-hands.
The thing is: you don’t have time to waste. If there is wasted time in your workweek, it’s worth looking into how to recapture that time.
You may find yourself performing a task while asking at the same time, “Why am I spending my time doing this, of all things? Something is wrong here. I’ve got better things to do.”
In this post, we’re going to cover what some of those time-wasting and motivation-draining tasks are. We’ll consider how you (or your project or your team) got into that mess in the first place. Then, we’ll look at how a unified platform can help you recapture that wasted time.
Let’s dive in and not waste any more time, shall we?
1. Patching bugs that shouldn’t have gone to production
At times, software developers are called upon with urgency to patch a bug that’s live in production. It’s stressful, but it’s understandable. Occasionally, bugs in the application code will sneak their way past our tests and make their way to production. That’s just reality.
However, certain kinds of bugs leave us feeling not just stressed, but incredibly frustrated—these are the bugs that we know shouldn’t have gotten out to production in the first place. Fixing these bugs can feel like a slog. What kinds of bugs are we talking about?
Bugs resulting from poor tests
If your test coverage is spotty, then bugs will slip through the cracks. Perhaps you’ve written tests for your “add user” and “delete user” endpoints, but you never got around to writing tests for the “update user” endpoint. When a bug in that endpoint code makes its way to production, your first thought is, “I know exactly how that got there. I should have written tests for that.”
If your tests are incorrectly written, then you’ll have a false sense of assurance that everything is working as it ought to. When this kind of bug shows up in production, it’s especially frustrating. Your thought is, “We tested for that, and the tests passed! What is going on here?” You find yourself burning cycles trying to hunt down code that’s buggy because your tests are buggy.
The solution
Spend more time writing better tests. The process of test writing gives you the headspace to focus on what your application should do. With a comprehensive suite of reliable tests in place, you’ll have fewer in-production bugs to fix, saving you headaches and wasted time. It’s worth putting in the time upfront.
In additions to writing better tests, Veracode Static Analysis and Dynamic Analysis will also help you avoid security flaws finding their way into production. Static finds bugs in the code itself while dynamic finds bugs at run-time. Using these tools together is the best solution for preventing bugs from getting into production in the first place.
Bugs in third-party code
Even worse than trying to fix bugs in your own code is trying to mitigate issues because of bugs in third-party code. These might be small and annoying bugs, or they might be massively impactful security flaws.
Coming into the end of 2021, software developers were wrapping up their final sprint of the year. Many teams were winding down and getting ready for a break. And then… log4j. Merry. Christmas.
Teams and developers were scrambling for two weeks in December. They needed to determine if they were vulnerable. If they used log4j directly, they needed to patch their code. If they used any libraries that were vulnerable, they needed to wait for those libraries to issue patched updates. Then the team could patch their project with those updated dependencies.
How many developers at the time were saying, “How did we get into this mess? Why am I stuck doing this? I’m supposed to be on PTO!”
Third-party dependencies with known security vulnerabilities should never make it out the front door. If vulnerabilities could be caught before the code makes it out to production, there would be less stress, less uncertainty, and less time wasted frantically trying to patch everything.
The solution
Software Composition Analysis (SCA) scans your application codebase to look for usage of third-party, open-source libraries. Veracode SCA cross-references any detected open-source libraries (and the versions used) against the National Vulnerability Database and a separate ML-backed vulnerability database. If dependencies with security flaws are detected, you’re notified. If any of your application dependencies use dependencies of their own (going all the way down the chain), those dependencies are checked by SCA as well.
By integrating SCA with your CI/CD pipeline, you’ll ensure that all of your third-party dependencies are checked before your application deploys to production. No more scrambling to patch libraries that are already out in the wild.
2. Dealing with technical debt
As developers, we often know the right way to do something. But, perhaps because we’re short on time or short on memory, sub-optimal code gets written. We might forget to sanitize inputs or parameterize our queries. Or, we might choose some algorithm for cryptographic hashing because it’s the first one that comes to mind, and there’s no time to research whether that one is strong enough or has been compromised.
Over time, we build up technical debt. We introduce insecure code, putting off the day when we’ll finally take the time to clean it all up or—and this is worse—when some security vulnerability in our production code comes back to bite us.
Whenever that day of reckoning comes, you will find yourself asking, “Who wrote this code? Why didn’t we just do it correctly the first time?”
The solution
Get help from your IDE.
First, take advantage of linters and code formatters in your IDE to help you keep your code readable. This is for you, but it’s especially for everyone who needs to read your code who isn’t you. Well-formatted code that sticks to common conventions is easier to maintain and debug.
Next, take advantage of static code analysis that can be integrated with your IDE through plugins. You’ll get helpful feedback on security issues or unsafe coding practices while you code. Immediately, you have access to security recommendations, preempting the introduction of technical debt.
If you and your team need training on secure coding practices, Veracode Security Labs and the Veracode eLearning platform are excellent resources to help developers level up their application security chops.
3. Refactoring (ripping) out unsupported or unlicensed libraries
Eighteen months into building the company’s flagship software product, your team receives a notification email that open-source Package X is reaching end-of-life and will no longer be supported or updated as of next month. Unfortunately, your application depends heavily on this package.
Refactoring your application to rip out the unsupported library is a non-trivial task. You might need to integrate a different library, or you might need to implement a workaround. It’s a sad reality, but you couldn’t have seen it coming. Not much you can do here.
Let’s consider another scenario. Your team discovers, after eighteen months of relying on open-source Package X, that the license and attribution terms for Package X don’t allow for its inclusion in proprietary software. That’s right—open source doesn’t always mean you can freely use it for any purpose. Left unaddressed, your application is about to land the company some hefty legal costs.
Again, you’re forced to refactor, to rip out the usage of this library. However, in this licensing scenario, you should have seen it coming. If someone on your team had done their homework on day one—discovering that you can’t legally use this library—then you never would have adopted and depended upon it.
As you’re refactoring, you’ll be kicking yourself for all the time you and your team are wasting by fixing a situation that could have been avoided.
The solution
In addition to checking for security vulnerabilities in third-party components, Veracode SCA assesses license risk. As SCA scans your application code, it generates a Software Bill of Materials (SBOM), listing all of the dependencies in your application along with a license risk rating.
Early in your software development lifecycle, when you are just considering the integration of a third-party open-source package, Veracode SCA will alert you to the legality of its usage. By letting SCA help you with your due diligence, you’re setting up your future self for less wasted time.
Conclusion
It seems that a common theme across many time-wasting tasks for software developers is the need to fix a flaw that could have been avoided had the right tools been used earlier. Those helpful tools might include:
-
IDE plugins for linting or static code analysis
-
Software Composition Analysis (SCA)
-
CI/CD integrations for static or dynamic analysis of applications before production deployment
-
Training in application security and secure coding practices
If you’re looking to recapture wasted time down the road—so that you can focus on the countless important tasks already on your plate—your future self will thank you for integrating some of these tools today.
