Saturday, April 30, 2022

How To Bridge The Gap Between Software Development & API Security: 3 Golden Keys

 


Just recently, I wrote a whitepaper for a client on an area of Cybersecurity of which I did not know too much about.  This area is known as “DevSecOps”, and it is simply an acronym that stands for Development, Security, and Operations.  But after I got done writing it, I learned a lot more about it than ever before.

Probably one of the biggest takeaways for me when I wrote this piece simply underscored the fact that Cybersecurity is a team effort.  It is a giant that no one individual can handle on their own, let alone one team. 

Rather, it has to be a collaborative effort with everybody in the company.  The second thing I learned is that there has to be a much better flow of communication between the software development teams and IT Security.

In other words, the old days of siloed approaches and thinking have to disappear and quickly, if we are to be successful in thwarting off threat variants.  The third key takeaway for me is that automation is going to be a critical area here as well.

Of course, it should be used wherever and whenever it can be reasonably, but it should mostly utilized for routine tasks, QA checking, and even for finding any holes and vulnerabilities in the source code that is being compiled.

This is probably the biggest area I hit upon in the content:  The need for greater security in the code.  For example, software developers have been left alone in the blame of Cybersecurity.  Traditionally, this has always fallen on the laps on the CISO and the IT Security team. 

But this can no longer be the case.  As I have said, everybody has a responsibility to protect the digital assets of their company, and yes, even the software development teams that you hire.

This one of the biggest focal points now for DevSecOps:  How to create and compile much more secure source code and streamlining the checking processes that are involved.  So, it is no longer the software developer that will be responsible team, it will also fall onto the hands of the IT Security and Operations teams as well.

The thinking here is that having two extra pairs of eyes will make sure that the Web application that is created either for internal or external uses will be the most secure ever.  But it is important to keep in mind that developing secure source code also involves making use of what is known as APIs. 

These are essentially open-source libraries that are typically deployed between the front and back ends of any web application that is being created.

These APIs typically consist of lines of code that can be modified, edited, revised, reused, etc. over and over again.  The main advantage of this is that the software developer does not have to write code from scratch, thus saving time and money, especially for the client. 

But the problem here is that these API libraries often come from software-based community forums which have not tested them, or have not upgraded with the latest patches and upgrades.

Because of the prevalence that this matter is now taking Corporate America, many businesses and organizations are now starting to become hesitant in using it. For example, according to the latest research report from Anaconda which is entitled the “2021 State of Data Science Report:  On The Path To Impact”:

*41% of respondents are fearful of using open-source APIs’

*23% of the respondents will not even allow its use anymore.

But let us face reality here.  Getting rid of APIs as a whole is not a good idea at all.  As mentioned, your software development teams will then have to write and compile new lines of code right from scratch, which is a task nobody wants to do at all.  So the key now is how to double check those APIs for any holes or vulnerabilities.  Here are some possible ideas that you can make use of:

1)     Everybody should be involved:

This is why DevSecOps exists in the first place.  The goal here is to have multiple eyes looking for areas of weakness that the other set of eyes may have missed.  One great way to get started with this are the frameworks that are offered by both NIST and the OWASP.  They have free, downloadable checklists that you can use which are fairly comprehensive. But you also need to have something extra in hand as well that fits the unique needs of the DevSecOps team.  This is where the Software Bill of Materials (aka “SBOM”)will come in handy.  This is also like a checklist, but instead, it lists the origins of all the source code that has been used to create the web application.  More information about how to create one can be seen at the link below:

https://www.darkreading.com/application-security/log4j-highlights-need-for-better-handle-on-software-dependencies

The SBOM serves as a starting point from which you can access the version history of the source code as it is being developed.

2)     Make use of automation:

I may sound like a broken record on this one.  Yes, I know AI and ML have been one of those techno jargons that has been thrown about and beaten up extensively now with a lot of hype into it, but I think (cannot say for sure yet) that these days may be over.  Why do I say this?  Well, it all comes down to the fact customers want real solutions now. They are tired of fake promises and fake results, they want something now that will truly work in their favor.  With this being said, the newer AI and ML innovations that are being carried out now do bring some solid value to the table finally. In fact, there are solutions out there now that have been specifically designed for the testing of APIs in particular.  Even though with DevSecOps there are more eyes available for scrutinization, they too can get tired.  But AI and ML automation.  Therefore, it is important that you make use of both.

3)     Contribute to the overall effort of the API:

There is often a tendency to think that by taking over an entire open-source project and bringing that in house is a good idea.  The common line of thinking here is that you will now have control of all of the APIs, so the checking and the repairing of them will now go quicker and smoothly, instead of having to depend upon others in the open-source community.  But, this can actually back fire on you.  This is often referred to as “forking a project”.  Remember, although open-source APIs are free to use, it does not mean that you can scarf the whole thing up, because others have contributed to the creation of them as well.  In fact, you will probably not even get the support and backing of the community that developed those APIs.  So rather than taking this extreme approach, it is far wiser to approach the community that developed these APIs and ask how you can contribute to further its cause in terms of ensuring that they are safe and updated to use.  Even remember here it, it takes team work to build a quality set of APIs that everybody can use and deploy.  More information about this can be seen at this link:

https://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareDev-OpenSource.pdf

My Thoughts On This:

If you haven’t noticed, the common theme here in this blog is teamwork, and that is now one of the key missions for any type of DevSecOps teams.  Remember, it now “takes a village” to combat the Cyber threat landscape, and in the future, it could very well even take more villages.  Finally, more information about the study from Anaconda can be seen at this link:

https://www.anaconda.com/state-of-data-science-2021

No comments:

Post a Comment

How To Improve Your Code Signing Process: 6 Golden Tips

  With the advent of AI, one of the biggest issues that face all businesses and individuals alike is making sure that whatever receive is ac...