At SourceClear I was recently tasked with finding a solution for dynamically creating cron expressions. As I had a look around at different open source tools, I couldn’t find exactly what we were looking for. Most of the libraries were very coupled to the DOM, essentially jQuery libraries, which didn’t fit our requirements. So I decided to create a tool to fit our needs and make it available as open source.
Preface: This is the kind of guide we wish we had when we were starting to learn Grunt. It’s lengthy, so if you want to skip that, there’s a handy gist that goes along with it so you can share in our process.
So you’ve got a last minute requirement to secure your customer data by encrypting it at the database level? Don’t panic. Take a deep breath, keep calm, and read on…
In my last post I discussed some of the higher level concerns and pitfalls with attempting to roll your own key management. In today’s post I’m going to dive into the details about how to do it without reinventing the wheel.
Nearly every company contains sensitive data, data that requires an extra level of security to ensure privacy, authenticity. and integrity. I recently had the pleasure of getting to explore and use Amazon Web Services Key Management Service.
On initiation, KMS may seem to be overwhelming and heavy handed when all you think you need is a 128 (or 256) bit key and an AES cipher, but read on and see how using just a few KMS operations can vastly increase the security of your data.
Here at SRC:CLR we are hard at work integrating our platform with the most popular dev tools and services. This usually means copious interactions with APIs, such as Github and Atlassian Stash. One thing I’ve disovered is that every API has its quirks that need to be worked around, especially as we try to normalize them as much as possible to simplify integration.
One common feature of these APIs is that they often follow (to varying degrees) the HATEOAS concept. For our purposes, this basically means that the API returns URLs rather than just entity identifiers.
Last week I ran into a security concern while working on an integration. I was taking the URL of a repository from one of our upstream APIs and feeding it into our Platform, when I can across something surprising.
Unit testing is an important aspect of software development. Having a proper test suite for your project can help detect bugs early and prevent regressions. Wouldn’t it be great if we could generate unit test cases automatically? Well, it is certainly possible and I will explain in this article how you can do so for Java.
Recently, I had a chance to look at unit test case generation for Java. I had forked an old cross platform serialization library wox and it did not come with a test suite. I had to make a few changes and fix some bugs in the library to make it work with the current version of Java platform. I wanted to ensure that the changes I made did not break any existing functionality. Since the wox library did not come with its own set of test cases it was difficult to check that no regression bugs were introduced.
I’m a pretty hardcore NetBeans fan, and have been since 2004. At the time I used it because it was the only IDE with a visual layout tool for Swing. Well, Swing is dead but I’m still in love with the IDE that does just enough to assist me in my coding but otherwise stays out of the way. But yesterday I was unexpectedly bit by a NetBeans feature that I don’t often use: code generation.
I seem to keep coming across advice recomending Agile development teams create “Security stories”. It seems much of this stems from SAFECodes Practical Security Stories and Tasks for Agile development environments and the OWASP Don’t Forget Evil Stories.
Yesterday I was bug testing new code for the SourceClear site locally and I noticed what usually is a red flag security issue. What I saw was this:
Recently I switched from using Eclipse to IntelliJ and haven’t looked back. So far it’s been a great experience but there’s always some things that I knew how to do easily in Eclipse and hadn’t needed in IntelliJ yet. As development has ramped up we started working on the backend of the SourceClear platform and doing most of the groundwork. With the initial backend work out of the way and Jason continuing the work I was tasked with starting on the front end. Oh the joys of being a full stack developer. I quickly found that re-running maven to do the deployment tomcat wasn’t ideal and looked for other solutions.