Foojay Podcast #58: How Java Developers Can Secure Their Code

Transcript

Automatically generated from the audio, so it can contain errors in names and technical terms. Suggest a correction.

[0:00] Three years after L for Shell caused a major security issue we are still struggling with insecure dependencies and injection problems in this podcast we’ll discuss how developers can secure their code welcome to the Foojay podcast all your news about OpenJDK in this episode of the Foojay podcast I talk with three authors who published a blog post about security and code quality on Foojay these are my guests my name is Brian verir and I am a developer Advocate or staff developer Advocate and engineer for sneak sneak is a security company which is based all over the world but is also active in the Java ecosystem with me being most actively in the Java ecosystem I am a Java Champion Oracle A’s I’ve been around for a long time as a full-time engineer and now in my role as a developer Advocate within sneak hello I’m Jonathan V and I work as a developer advocate for sonar source that it is the company behind products or famous products like sonar Cube I’m also part of the Java community in Barcelona and one of the founders of that bcn I’m Eric cell I’ve been in Java for over a decade now and application

[1:23] Security for even longer than that my absolute expertise is really the union of java and application security because if we’re one of the most popular languages we better do that safely let’s start with Brian about his article the persistent threat why major vulnerabilities like L Force shell and spring for Shell remain significant I asked him what the problem is with insecure libraries well the problem is that we probably all know about log for Shell let let’s keep that one that was the biggest one of the two and that was a major vulnerability that was I think from top of my hat dis closed or at least published December 10th in 2021 I mean we’re now in 2024 but what we found out is that there is still a significant amount of applications around that are using these vulnerable dependencies like this vulnerable log for J library and they are still out at least we don’t know how much is deployed but we can see that the code is out the code is still available either on GitHub or with our own customers or something like that and still people are using old versions of these libraries which I don’t have to

[2:42] Remind hopefully I don’t have to remind people how significantly significant that threat is because log for Shell hit the news as a CVSs score 10 major vulnerability when it was easy to inject Cod however we will see that if this one which is a top vulnerability which hit National and international news is still surfacing because people are still using the old libraries what happens to the ones that are not a 10 but a nine or an eight or a seven that’s scary so that’s why I was looking for it as in hey how many applications are still using this and yeah that was interesting I think you can also see that in the number of downloads in the MAV repository so they also have charts about which version is getting downloaded and so that means that there are still builds running every day on a system pulling in these old outdated versions with vulnerabilities yep so that’s that’s the biggest issue well part part of these builds are mine because I still demo these things obviously so yes but it’s not thousands like maybe a couple of builds a week are mine as in

[3:58] I’m still maintaining vulnerable applications for the reason of demoing so just want to say it will never be completely zero yeah but the amount now is insane so if we go down to a few per month then it’s you and then we know it’s fixed probably it’s me and my colleagues or some somebody in like in other security trainings and that kind of stuff to use it as awareness pieces but yeah if it’s a it’s down to a couple of a couple of hits per month then we then we’re fine who is responsible is it the developer thing should we as developer fix this who does interest interesting question I don’t think we can put the responsibility on a single person or a single group U let’s face it like we’ve all worked in companies and as part of a larger engineering team or something like that and it’s also like where are the priorities so yes as a developer you have a significant input in that but don’t get me wrong I’ve been in companies where there were product managers and C Level managers and breathing down your neck to get that new feature out and if they say like well

[5:13] It’s not that important or we don’t see the threat in that because we think it’s only internally facing or something like that yeah then still it’s it remains if we downplay the significance of such a problem then that’s that’s one thing why it happened so it’s not just to blame a developer absolutely not we all know how we need to work on the stress as in we need to get this feature out today right secondly I am not sure if if some things are even maintained I like like if you work in a very conservative company is it even possible to upgrade to a newer version of lock for J in this case or this the other one was spring for so the spring one which was less significant but still significant enough if you’re still on an old stack and that thing is running in production it can be hard to update to the newer version because that breaks API that means your whole stack needs to be rebuilt with newer versions so it can be that it’s either pretty impossible and people don’t want to do it it’s impossible that though they don’t have capacity it’s possible that

[6:25] There is no priority for that I think it’s a more of a cultural and companywide aspect yeah but you have to go back to your sources update dependencies build it again so you really have to go back to the build process to be able to fix this yes yes and I think well I think the other thing that we that we see over here that if it’s outdated or you’re using an outdated version how outdated is it so that means are you doing any maintenance on an application that in production which be backs the question like how do you how do you work with that in general because then you’re not only having a security problem but you have a maintenance problem in general because if your version of whatever is like five major versions behind and something happens like this one you it’s impossible to just update that means you have to rewrite probably your half of your applications because everything changed so it’s it’s it’s connect next to a lot of stuff that we hold there in software engineering but yeah this faced my eye or this I

[7:38] Caught this one and I thought it was interesting to write about it after like almost almost four years or almost three years sorry yeah three years so it’s three years for lock for Shell it’s two years for spring for Shell so indeed they’re still there y yeah you working for Snick I guess you as you write these articles I guess you also have a solution or a way to help people with this kind of problems obviously we have a solution as in we do have products that and free products you’ll get me wrong to help you out with scanning your dependencies and even knowing that something is vulnerable and if there is an updated version that fixes that particular vulnerability and why I say that particular vulnerability because it the depends obviously on your use case how important an vulnerability is some lower or medium level vulnerabilities you might be okay with depending on what the service of your application is however this one the thing is we can point out for a vulnerability hey okayy you have that in a certain library and you can update it to a new library or if it’s part of a

[8:55] Part of a bigger dependency say it’s a transitive dependency as part of a spring boot starter or something like that you can update to a newer spring boot starter or any top level dependency that encapsulates that problematic dependency like that log for J Library so we try to help people with that also if you connect to our systems we can help you by updating it to updating it to newer versions even if it’s not a security problem so say there’s a newer version of a Json library or an XML parser or something like that there’s new version out we can help you with updating it to newer versions if you connect it to your git repository for instance we can create pool requests so you are up to speed and if something problematic happens U it’s not such a big impact like the Delta between where you are and where the newer version with the fix is quite small in that case so yeah that is things that we can do however we cannot help if you are like no it’s not a problem if it still works don’t fix it we can only point the problems out and it’s up

[10:10] To it’s up to an individual or an individual company to actually do the fixes is that also a bit what dependa bot in GitHub is doing so automatically they are alerting you for certain security related yeah depend dependabot does a similar thing I will not go into product details and comparison but yes if you are on GitHub and you have the pandabot helps you already a bit to updated to newer versions when there are problems and even if there are newer versions available but again if you already have something like what are the what are the problems how can you fix it if if what if there is no newer top level problem say there is no new spring starter for you but you have a problem underneath to what version of minor version of Log4j or whatever Library can I update manually by overwriting it in my Gradle or Maven pum file like we give you that information but yeah dependabot does a similar thing on the dependency updating but yeah all these tools alert you if a vulnerability happens but if you wait for a

[11:28] Vulnerability you can indeed get very outdated dependencies and that’s probably I think for a lot of developers companies a big problem because spending time on only updating dependencies and updating your code because you’re updating yet that doesn’t bring a lot of value immediately no that’s true it doesn’t bring bring a lot of value immediately but we have to pick it from two sides I guess one of the things is yes we have to do this like it’s part of a routine if you buy a car it needs annual checking and in some countries we have like it needs to be annual checked to make sure that even is allowed to drive on the road if you have if you buy a property if you buy a house it needs maintenance to make sure that it doesn’t collapse but also that you’re insured like if you’re if you just lack the maintenance your insurance will say yeah that’s on you why aren’t we doing the same with software like why do we think this is a burden it’s something that we serve to our customers so we need to put maintenance in and we need to take time for that secondly we can automate a bunch of

[12:41] Stuff of that by the tools that we just that we just discussed on to see what kind of problems are there surfacing and for instance we can already give you a pull requests on updates like hey this is there you just have to click okay and I assume that you have a test Suite so that’s another thing like if you have a extensive test Suite you can already test the poll request to see if it’s if it is a problem if a new newer version comes in and if it is it’s just a small fix if we wait it the fix will get bigger just like if I have a leaking roof here and I will just leave it will only get bigger so it’s it’s a it’s a mindset but also there are enough tools available to help you automate half of it so that you don’t have to manually search for these kind of things or like put your mind to it as in if if a tool pinks you there’s a new version they’re like okay we need to take care of that and at least you can put it on your de board or whatever board with a certain priority but then it’s up to you how to how you prioritize this same same as maintenance to your car your house or

[13:49] Anything that you own I like the comparison that’s really that’s not how many people look at software but it indeed it needs maintenance it needs maintenance and what we see if if we weally go into software is that we build something as a pro of concept very small and then we build things on top of that can you imagine that we do that with a building with an actual structure that is insane because then we say that the foundation is not built for this but for software we do exactly the same so we just connect bits and pieces to each other and no wonder things go wrong or we don’t know anymore what the intention was of certain code so we have a bigger problem in software engineering I guess and maybe that’s that’s maybe a good responsibility for developers one of the biggest advantages of the Java system is all these libraries which are available but then and i’ I’ve made the same mistake do you end up with projects where you have three different dependencies all helping you with XML because you found some example code and this dependency you just smash it all

[14:57] Together but reducing the amount of dependencies and then also maybe looking into Evolutions within Java itself at some point also removing some need for dependencies that’s also a responsibility for developers I guess absolutely like do we need that third or fourth XML parser while there is an XML parser already in Java like and you will see that because there’s pressure on developers in Enterprise like like let’s call about let’s talk about Enterprise development there’s pressure on developers to get that new feature out I understand like we need to get it fast it need to work because my manager doesn’t know how it works and he just wants to see results yes I’m downplaying it now a bit but you know what I’m what I’m saying so absolutely who cares if I put that another dependency in well in the end for the maintenance of stuff it does matter also like do you have dependencies in that are still there and that are still packaged in your artifact that you’re not even using anymore mhm and most people hopefully most people know that but things like Maven and Gradle

[16:09] Have plugins to check if a dependency is used or not if it’s declared but not used and even I know in at least in Maven and both in GR is there there’s also a plugin but we can already check if there are newer versions available on Maven Central of a newer version so you don’t even need a tool you can do it just with your package manager and these things are already available but you have to build that into your routine or into your build pipeline or whatever you want to do it but yeah dependencies that are not used or dependencies that are there multiple times or similar dependencies that are there that’s definitely a problem we have to we have to clean our house up I mean I know my office is a little bit of a mess but guess guess guess what if my wife comes in like come on you need to you need to clean this just like back in the days when my mother was looking at my bathroom like Brian need to clean it up that’s also happening that’s it’s the same for software clean clean your stuff up like do we actually need it do we need to pull a new dependency in do we

[17:15] Already have something that is there very nice message to conclude another question I see you’re wearing a sweater of the nlj are you ready for jall almost in we just finished as in a week ago we had the program committee meeting about which talks we’re going to pick just to give you an example like we had over 450 submissions and we have about 50 55 available spaces if I just take all types of talks in accordingly so that’s that was a hard thing to do we’re almost done with the schedule so yeah everything is going according to plan we’re not there yet but we still have we have some time left it’s November 7 it’s it’s it’s it’s in November so yeah November 7th and like everything going according to plan and we already invited the speakers that we want have and we will be there with small team of Foojay to also have some interviews again live on the conference floor so that we can talk to the Java community and see what’s what questions there are what people want to know what people want to learn so that we can maybe generate some

[18:41] New content also for the website okay thanks a lot is there something more you want to add no I just I want to ask everybody to keep an eye on Foojay I mean it’s amazing that Foojay is there for about five years now if I’m not mistaken yeah probably maybe maybe even longer and every day there are new articles and some some might overlap but like if you can see the amount of content that is Created from all over the world that is aggregated into Foojay I think it’s an amazing platform for everybody that is either starting in Java but also who are seasoned developers there’s always something that you can pick and read and stay on top of on so I just want to thank you for the initiative you and the rest of the Foojay team and keep doing this I think it’s amazing and thank you for your articles because we wouldn’t be there without all the authors that are writing and sharing their content which is also a call to other people who have something written on their own blog on the company blog which is Java related gvm related cotland they can all share it on Foojay

[19:48] Okay Jonathan Villa’s article top security flows hiding in your code right now and how to fix them about various injection problems made me wonder if SQL injection is really still a problem it’s not long enough I mean that there have been issues on related to SQL or no SQL injections there has been issues on mongod TV databases even in the famous game fortnite so they had a bridge in 2019 but the thing is you could say well it’s 2019 right so we are in 2024 but we need to think that there are applications already running created years ago they are not patched and we are even creating applications without having these issues in mind and if we check how many applications have been created created following the proof of concept trapped where you create a proof of concept yeah because we are going to create this PC and then trash it but then that PC becomes a production thing months later and you didn’t put a lot of effort on thinking about these vulnerabilities or injections and now it’s in production and you are using parameterized U statements and you using concatenation concatenated

[21:38] Strings because that was faster I don’t know but then you suffer from yeah yeah and EAS it to write yes yes so the main problem is if you just accept any string input from a text field or whatever and use that in your quiry then you could have some smart guys or woman making some very funny inputs that actually breaks your database yeah yeah yeah you gave an example with Tesla they also had an issue like that yeah with but it was in 2018 related to the kubernetes console apparently there was some SQL injections at that time and well attackers had even permissions in order to run things applications on those clusters they use that power to run crypto mining applications so a lot of power were invested on yeah and they some money so yeah and it’s a hard problem to solve on the server side within your infrastructure you cannot solve this really because yeah if it’s in your code that you’re creating these queries and they are reaching the database there’s not much you can do there except changing the code again it all depends how you define your

[23:23] Infrastructure I would say I’ve seen ways of solving or mitigating the lock for Shell vulnerability without touching the application code just because they were using service mesh if you are using applications that are controlling the networking between your applications in this case with uhto or enoy proxies then you can introduce filters that can sanze I somehow those inputs from the user mhm definitely this is a way of mitigating the problem but I would say the best way would be to fix the applications but I would go even further that it is the main goal of this article is not about teaching you how you can modify your current applications yes that’s that’s one side of the article but it’s it’s just making you aware that there are those injections problems and that it’s it’s easy to prevent them investing few seconds or even using tooling to that can help you in order to prevent those those issues so in the article it’s not only about SQL injection you also mentioned deseral deserialization injection who that’s a difficult one yeah what’s the problem there yeah well

[25:03] Basically if we are using any this realization mechanism that means we have a Java object we convert it into a bite stream then we send it through the network to a server that will take that by stream and we will create a Java class Java object from that stream because this is a way of sending information okay usually you expect that the class that you are going to receive is the one that you are expecting who is going to send a non-authorized a class right sometimes we rely on the front end checks so okay if the client side is doing their thing so I have a client connected to my restol application back end and yeah I expect that some Che some checks are made in the front end but what happens if someone connects directly to our backend application and sends something that it is not accepted well in my example the thing is you send a wrong Class A wrong object and everything happens as it expected yes the ban says this is a wrong class I cannot handle this request fine this is the expected output but before saying that there are some things that are happening that are being

[27:01] Executed that can harm our system and people can just simply I don’t know remove files create files even open the calculator this is a usual example just because they are sending an object that has been serialized containing some methods that will be executed before trying to do the typ cast y oh yeah and is that then the same thing which also happens with logging injection something gets logged and is able to execute something well with the logging injection injection what we can suffer from is well two different things one is that the user can send information along with the data that they know this information is going to appear in our locks and then it will make us way more difficult to find which is the problem or even it can introduce some information that oh can make the person that is reviewing the lots to be puzzled somehow that’s called lock forging that well they are creating information that they know it will appear in the log but also what we can have is remote execution so for instance with the famous lock for Shell vulnerability they are using

[28:44] In this case El up in order to do lookups M and before the patch in Lo 4J this feature was enabled by default so people could just simply add a text in the user that they are typing in the front end and then Log4j is going to try to execute that code and then they can introduce some bad code in our system there are ways of preventing this especially updating to the latest versions obviously also disabling lookups that it is something that it is by default in the newer versions but it could be that in some cases we still need lookups m in all the cases we need sanitizing that’s that’s important part what I also always have learned is in logging you should never log any kind of sensitive or personal information like even logging an email address of someone who is signing in is already considered it’s not not an injection but it’s not safe or not complying with what you should do with personal data you are totally right depending on the laws but yeah definitely you never know who has access to that lock files sometimes we don’t think there is any special information in the log files so

[30:19] We don’t put extra effort on protecting those log files but it could be that some someone is logging user and password it could be that they are logging I don’t know tokens M that if someone has access to those log files then they have the keys to enter the system yeah I have to admit I have definitely locked passwords at some point because I wanted to be sure that my form arrives at the server and the information is correctly passed so yeah it is definitely something to think about what do we put in the logs I even read a Twitter or a mustone message that you should add sometimes in a field the Y with two dots on it because that asky code is 255 so that appears in your logs as FF so you can really annoy developers if you use some certain characters and do stuff like that yeah yeah yeah exactly we are putting the focus on yes I did deser ER before yes you need to put attention on it but we are experienced developers and we are still sometimes failing because we create a POC we don’t put effort someone takes that someone evolves that and the first goal was not to be a

[31:52] Production ready application therefore you didn’t put extra effort but in the end it becomes a production application so it could be that even the most experienced developers sometimes introduce issues just because MH they did not expect that was going to production even the case that you were mentioning I log passwords you didn’t do that on permanent status so what you wanted is to debug something fix it and then remove that debug line sometimes we forget about removing the debug line so that’s why we need some kind of tools that can warn us if we are introducing some some of those issues that can easily skip our mind whenever we are putting the code into the repository yeah don’t you become a senior developer by making mistakes if you earn enough mistakes then you become a senior developer and I don’t see I don’t see any other way of becoming a senior developer yeah and if you break the production system then that’s even a bigger Point yeah definitely yeah we talked earlier in the podcast 46 at Jon I interviewed you there and talking there about Java

[33:27] Community and you work at sonar sonar is a code validation tool that you can use in intelligy correct Can this tool warn us for errors like this yeah so sonar has like a set of applications one of them is as you mentioned the linter so the ID plugin that can connect to sonar Cube that is probably the most known tool for this that will analyze your code and we check for issues regarding errors vulnerabilities even design or bad design patterns or a lot of stuff and sonor lint is the tool that will run in the IDE that will check these issues at the and will warn you that hey you need to fix this and not use lookup in the loging or you should not use string concatenation in when you are creating queries or if you are the deserializing objects it will warn you also about it so it’s sonal is one one of those tools there are others obviously I’m a bit biased because U but definitely having these kind of tools in know ID that can prevent us from committing bad code will save us a lot of problems and a lot of work sometimes I’ve seen when do you fix

[35:14] Your Tech dep or your issues well we create a Sprint for that that’s that’s not the good approach it’s it it’s hardly to be a reality in some cases so you postpone and postpone it so the best way is to fix it before committing the code and that’s what you want to achieve with your article is that developers are aware of these issues when they are writing SQL for instance yeah exactly so basically it’s about as I said these kind of tools not only warn us about issues or vulnerabilities these kind of tools can also help us a lot in the case in my article about Java 21 there are some things some features that we don’t know about Java 21 that we don’t know about Java 22 23 so it’s important to have something that will analyze our code and we’ll say hey there’s a new API in Java 21 that can help you to do this in a better way in a more consistent way so we need to take advantage of those tools in this case for Java 21 and also that’s the other article about the top issues in that case from sunar we collect a lot of information Telemetry and we know which are the top

[37:03] Issues that happen in open source projects and sometimes we don’t we don’t think that can be possible but one of the most common security issues in the projects being analyzed is hardcoding passwords it was hard for me to believe that when I saw it but yeah it’s thousands of instances of this issue happening in all the projects being analyzed by in this case hlin it’s incredible but yes it is what it is so I think we have an ideal idea of what the code should be but the reality is way different and yeah there are lots of issues not very complicated if I have a talk talking about those those issues and when I ask people about those issues people say yes it’s it’s obvious you shouldn’t have code code passwords yeah but this happens happens yeah and then we luckily have the tools to warn us about that I think like for instance GitHub projects it also if you commit something like that a password and it recognizes it will alert you yes exactly GitHub also has the SQ the security remember exactly the name code ql is the technology behind it and it will also check our code or certain

[38:44] Rules in order to warn us hey you shouldn’t do this yeah yeah there are lots of tools out there and but we need to think about having one if it can be sonar it’s it’s better it’s not only that I am biased working at sonor but also that well those tools have longtime experience they have been in the market for more than 15 years now and we have lots of rules even well for more than 30 languages and yeah the coverage is huge so but in any case using a tool that can check our code it’s definitely the best thing that we can do okay good okay thank you thanks for the great article of course the link will be in show notes I didn’t think we would ever talk about pandas in this podcast but that’s exactly the topic of the article by Eric costlo he discovered that trash Panda love Enterprise Java garbage coat and those thrash pandas seem to be attracted by unused coat yeah I just think it’s fun to have a topic everyone takes security so seriously that they kind of lose sight of what they’re doing and I think if we just inject some fun into it we can get better results and also enjoy

[40:15] What we’re doing so trash pandas are it’s a nickname for a raccoon and since raccoons love hunting through the trash and some of the times let’s face it we refer to our code AS trash let’s just talk about stuff that we can throw away so the joke of trash pandas I really just thought it was funny yeah indeed so the article is really about unused codes what’s the problem with that part of our code yeah the article was about unused code and how as Engineers we tend to write a lot of new things but we never really throw anything away so we leave a lot of that old Legacy code in there and we just go back and you know we kind of hoard it and we say well I might need this fun function someday well trash Panda article is about the idea that instead of us going through and hoarding all that code if you watch it and you realize you know what I don’t use this method you can throw that method away it’s possible to get rid of some old things so for all these libraries and security problems that people have where like there’s a really old library and you know people just say well I have to

[41:21] Update that Library what if you don’t have to update it what if you don’t use it and you could just throw it away mhm so it’s not only about the code that we write ourself and becomes unused at some point it’s also that we are have a history in a lot of projects of old dependencies outdated dependencies maybe dependencies we don’t use anymore yeah I mean as Engineers we love to go out there and take advantage of other people’s work and I love to go out there and grab a library if you have a function I want if you have a feature I need I’m going to go grab your library well over time as a lot of people work on applications and something’s been around for four five maybe 10 years or more different people who worked on the application have grabbed different functions and I’ve seen situations where people have you know five or six different ways of generating a PDF I’ve seen things where there’s multiple libraries in a project that do pretty much exactly the same thing but in different ways well if you go to look at the way that your application works you don’t need all of those older

[42:28] Libraries often times you have a transitive dependency that comes in you have different things that you added a while ago and you switched but you never took the old libraries out so those vulnerability scanners are looking at your code and they’re saying you have an insecure Library over here you better fix that you’re bad but if you actually look at the application the library is never invoked so instead of fixing it and patching up to the latest version what if we removed the things we didn’t need and then just didn’t have to deal with them anymore mhm is it an issue if I have a library which has a security flow and it’s not invoked is that still a threat somehow I think it depends on people’s risk tolerance a lot of groups the security teams are so stressed with the series of things that they have to look at that they just play this Zero Tolerance game and they say if you have it you’re at risk but I’ve seen other Java applications like m moft like some of the larger application servers they had a lot of Frameworks that people didn’t actually invoke so moft in particular ships with like five or six

[43:36] Different versions of spring well when I go to deploy I’m only going to use one of those so a lot of these security scanners they just go through and they look for what are the files that are there in that file system you have you know vulnerable jar 1.2.3 or they look at the build chain and they say for the course of your Maven or Gradle build you bring in this version of Log4j that you’re not supposed to have well when you watch the application it never actually runs so is the risk real technically yes the risk is there and something new could always happen but a lot of these applications you look and you say are you actually using this code there’s no path to executing it so the tools I don’t want to say they’re wrong in saying that you’re at risk but the level of risk of concern is really low because there’s no path to actually execute the vulnerability and in fact the code that it’s contained in literally never runs at all in the article you mentioned something like you should treat unused and de code similar to the garbage collector so you let the gvm do the work is that a good idea from

[44:50] Developer point of few yeah I mean the whole point of Java or one of the main points of it is that it takes a lot of the work that people should have to do and it does it for them it does automated memory management I don’t have to think about how I use objects as much because the JVM will clean things up for me there’s different ways that I could go through to hunt in my code and say do I actually use this I can run some coverage testers in a test environment that’ll give me that data I could instrument my code I could throw logging statements everywhere but why should I actually do that like the JV m is able to know when a method is being invoked and especially when it’s being invoked for the first time so why don’t I just make the jbm tell me that information if the JVM tells me I already have enough work on my cognitive plate I don’t want to have to go and figure out things that the JVM can just do for me I know as a developer as soon as I write the unit test to test a specific method that method becomes used for my IDE so it cannot alert me again yeah this is actually code which is not used

[46:02] Within your application because it’s used by by unit test how do you fix this yeah so unit tests are really important and I think they’re really good but we need to recognize that over time technical debt builds up both in the code in the requirements in the way we think about it and also in those unit tests that are designed to keep us safe from introducing breaking changes so what happens is over time people write a piece of code and they do the right thing and they write a test later on they stop using that code but they never delete the test or the code so you end up having a lot of unit tests that exist only for the purpose of making sure that the thing works the way it did a long time ago there’s no re-evaluation to say do we actually still need this unit test so the way that we address that within U the aul JVM and intelligence cloud is we track what you run in a production environment and we track what you run in a test environment and we give you the ability to see the difference so what you can tell is where am I spending time maintaining tests and worrying about green bars on things that I don’t

[47:10] Actually use because you can actually get rid of them so you have these different levels of test so I also talked with Jonathan Villa about what he thinks is bad in code like SQL injection that’s also something we have veler should be aware of but his tool like sonar can alert you in the IDE you’re doing something wrong here there are also tools like Snak which run on the build server then we have intelligence Cloud on the production system do we need all these levels of checks the level of check just depends on what you want to look at and where you want to see it like it’s always good to do things early but over the course of looking at my code itself I build up a simulated execution model the benefit of like operating inside a production environment is you get to see the actual things that happen so the way that different code combines via reflection via like Google guava nobody actually or very few people actually call into Google guava you just get a collection and it implements the collections interface so it shows up so when you’re watching in a production environment if

[48:24] You look at the code level there’s no references to guava but when you actually watch the code execute there it is so it just gives you a different level of granularity and then you know the whole point of the devops being an infinity symbol is that there’s information that comes back from the production environment so that’s what we’re providing is watch your production environment and bring a signal back so that you can take action on it so actually testing in production that’s what you’re aiming at it’s not I wouldn’t really call testing I would just call it watching M so that you have a real image a real view on what’s being used in production how your system is behaving and what code is being called dependencies are being used exactly like is Log4j a threat well on paper if I have that V that Library you know yes it’s a threat but if I watch the application and it turns out I’m only using the API and I’m actually kicking it over to one of the other eight logging Frameworks via like SLF4J or something there’s all kinds of ways to rewrite and remap that with your system now being used in production do you

[49:36] Already have results of how much code of some applications is not used yeah so over the course of watching a lot of applications execute I can say if I show up to a room of java engineers and pick anyone out of there I’m going to see between 10 to 30% of Their Own code does not actually execute and that’s a pretty safe guess so that I know I’m going to be right because I don’t like to bet but if I go to watch an application and I pick one and I kind of get lucky I’ve seen people go up to 50 or even 2third of an percent of their application just totally unused where they can highlight it hit the delete key and it’s all stuff that was written a long time ago so imagine the thing that you work on every day just realizing that you can get rid of 2third of that workload and how does this happen is it just historical applications get larger the use case changes developers come and go within a company there’s a lot of ways developers come and go in a company we write new things there’s a lot of causes of why we can say it happens or not but what I think is that it’s a lot easier to write code than it is to read

[50:56] Code code so often times we write a new function we come up with a different way of handling some things or we go and we create a new function to fix a bug and we just leave the old one lying around it’s just a level of Maintenance where you know we tend to keep the older thing around in case we need it and we always say I’ll come back to delete that later well later never shows up so after you know a couple years of an application being live you have a ton of unused code it’s funny that you mention mentioned the readability of code because we just mentioned or talked about this in the Java 23 podcast that’s the goal of all the evolutions within the language making the code more readable and then also maybe moving some Library functions into the Java code itself making it also easier to read and to develop yeah I I’m all in favor of legibility of code the code that I write I tend to spend time making it look clean I love my IDE based formatters I wish Version Control Systems were format agnostic because I just want that code to look easy to read it makes working on it so much easier

[52:09] Yeah and then being able to remove all the de unused codes and making it smaller that you only see the things that are really inuse that’s that’s also a big benefit I guess right imagine you go to read a book and one of the chapters has nothing to do with what the book is actually about when you realize you don’t need something instead of leaving it around you take it and you throw it away I know it sounds scary but it’s still there in the Version Control repository you can always get it back but don’t leave it just lying around to walk through every day it’s nice that you mention Version Control because that’s also one of the guidelines never command code if you think it’s not used anymore then just delete it you can still go back to your history in your repository when people delete code without really knowing that I think is what gets people nervous about deleting code because some of the times that you’re wrong some of the times if I go and I say I think this code is unused there might not be any static references to that code it could be something that’s invoked dynamically so if you

[53:18] Just go in there and you say I’m going to press the delete key and I’m going to see what happens that’s a really bad idea watching in production and getting a level of signal that says no this code never actually ran it’ll confirm for you no I never saw that code it’s safe to delete so I would watch a little bit I wouldn’t just randomly take a guess and play Russian roulette with that delete key watch in production get a signal and after you watch a little bit you know maybe you’re suspicious about something so you only need to watch for a week thanks for all the advice all the tips something you want to add still really really it’s just a matter of getting comfortable with the idea that you don’t need all of your code when I look at an application like I said it’s an average 10 to 30% of someone’s code is unused think about when you work on your application never having to look at that code again never having to deal with a new security alert that comes in and says this library is vulnerable if you don’t need things if you aren’t using them instead of patching it instead of doing maintenance

[54:27] On it get rid of it as developers we are responsible for the code and dependencies we use in our work keeping everything up to dat and secure is a challenge but luckily we have the tips of these podcast guests and several tools we can use to keep an eye on what we write and run in production thanks Eric Jonathan and Brian for your articles and joining the podcast and thank you for listening keep an eye on Foojay for future articles and podcasts about development and everything related to the Java World thanks a lot give me a give me a me the of OpenJDK