devopsy.kinsta.cloud

Tag: sdlc

  • Navigating the Rise of AI-Generated Code in Software Development

    Navigating the Rise of AI-Generated Code in Software Development

    The year 2023 saw the rise of many technologies and innovations, but none quite as prominent as generative AI. Trained on vast amounts of data, these models are designed to “generate” the next sequence of values based on inputs and create novel content for various purposes. The emergence of generative AI has forced industries to rethink how they operate and where adjustments should be made. A recent study from ISG indicates that financial services are the leading industry for generative AI adoption, making up 24% of total use cases. This is followed by manufacturing at 14%, healthcare and pharma at 12% and business services at 11%.

    More recently, organizations have started contemplating generative AI’s impact on software development and its ability to effectively generate code. AI-enabled tools will have a major impact on software development, increasing the volume and velocity of code delivery and innovation. However, there are ethical and practical guardrails that need to be considered.

    Key Capabilities of Generative AI in the SDLC

    The advantage of AI tools lies in their ability to enhance the software development workflow by automating repetitive tasks. Mundane and time-consuming boilerplate code generation or routine code reviews can now be handled by the same machines that we are writing the programs for. This not only accelerates the software development lifecycle (SDLC) but liberates developers from monotonous tasks, allowing them to focus on more creative projects that require human insight.

    For developers, the strength of AI-enabled tools lies in their ability to expedite the development process. By harnessing machine learning (ML) algorithms, AI can analyze vast datasets, find patterns and generate simple code quickly, often requiring numerous iterations to get it right — hopefully! But at its core, the benefit of AI-enabled tools stems from the premise that it’s easier to refine a set of initial ideas than it is to generate them. In other words, generative AI models create the “sparks” that a good developer can turn into a full creative process.

    Challenges, Concerns and Ethical Considerations

    As the adage goes, there are two sides to every coin. While AI tools hold the power to provide immense benefits to developers, they also introduce an array of risks that cannot be overlooked:

    ● Challenges in understanding context and user requirements: Despite its sophistication, AI struggles to grasp the intricacies of specific project contexts and the diverse needs of end-users. The contextual understanding that human developers possess, gleaned from experience and intuition, is still a facet where current AI encounters hurdles.
    ● Potential security risks: The automated nature of AI-generated code introduces potential security risks that demand careful consideration. While AI algorithms strive for efficiency, they may inadvertently generate code with vulnerabilities. Addressing security concerns requires ongoing vigilance, thorough testing, and the incorporation of robust cybersecurity measures to ensure the integrity of the developed software.
    ● Adapting to evolving technological environments: The dynamic nature of technology presents another challenge for AI-generated code, as rapid changes in programming languages, frameworks and methodologies require an adaptive approach. AI models may struggle to seamlessly transition to new technological advancements, potentially causing compatibility issues and requiring continuous updates to maintain relevance.

    It’s important to note that developers will not be the only ones affected by AI’s integration into the SDLC. Security teams are barely keeping pace now, and in many organizations, they’ve become the bottleneck. Increased developer velocity will put security teams under even more pressure—the volume of scans, the range of vulnerabilities and the patches that need to be applied are all guaranteed to skyrocket.

    Automation Alone is Not Enough; We Still Need Human Developers

    While the introduction of AI marks a significant milestone in the evolution of software development, it’s essential to recognize the nuanced interplay between automation and human ability. Rather than replacing human expertise altogether, generative AI is poised to augment and complement the skills of developers. Human creativity, critical thinking and the ability to navigate complex problems will continue to be invaluable assets in the development process — true potential only appears when collaborating seamlessly with human developers, blending the efficiency of automation with the creativity and problem-solving skills inherent to human intelligence.

    Looking towards the future of software development, the trajectory of generative AI presents intriguing possibilities. It has become increasingly clear that the rise of AI-generated code is not a story of replacement but one of enhancement. While AI brings undeniable efficiency and automation to certain aspects of coding, the role of human developers is still irreplaceable. The understanding of context, the intuition required for creative problem-solving, and the adaptability to evolving technological environments are hallmarks of human expertise. These are facets that, as of now, AI struggles to replicate.

    As we embrace the future of AI-generated code, let us not forget the essence of our craft. The evolution of technology is inevitable, but it is the human touch, ingenuity and ethical foundation that will define the software landscape of tomorrow.

    Image courtesy of Josh Calabrese via Unsplash

  • 2024: The Year of Testing

    2024: The Year of Testing

    Caveat: I currently cover DevOps – including test – and security – including the *AST. This does give me a viewpoint that others may not have, and also potentially gives me blinders that others may not have. I am not generally a predictor but a reader of direction. Proclamations like this are rare for me and are shorter-term/more tactical than the grab bag of predictions usually seen this time of year.

    I was thinking about this one this morning; the direction of travel of traditional and security testing is very similar at the moment. We are seeing the vast complexity of the overall space and the rapid growth of automation come together to once again make all testing a topic worthy of consideration.

    I loved test-driven development (TDD). I can’t speak for others, but RPC/API is just a cool way to implement centralized functionality, and TDD is almost mandatory to develop APIs and the clients that call them. There is no UI to distract or have separate requirements in API development; there is a stated function and correct or incorrect behavior. To a computer scientist, this is predictable beauty. TDD made it more than predictable—it made it a trail through the woods. “We know it needs to do X, Y and Z, with the only side effects being A,” can be detailed with tests to prove that is what it does, and then look to prove the “It doesn’t have other side effects” part. And you can do it all while developing—no need for dev/test iterations. Like any IT solution, it isn’t a great fit for everything, but even if it isn’t called TDD, it is nearly impossible to develop API-based solutions without some level of TDD.

    The thing is, TDD is absolutely a developer’s tool. Developers and DevOps pretty much must use it to turn out usable APIs. The test team only has a use for a subset of those tests. Because if the dev team did it right, they passed all the TDD tests, and the test team’s role in that scenario is to look closely at what the developers might have missed. Integration is often beyond the control of an individual dev and/or API, for example, because many different clients may be integrating with it. Test teams, in a true TDD shop, fill the gaps with meaningful tests that evaluate the overall application quality.

    Security testing—at least static application security testing (SAST) and increasingly dynamic application security testing (DAST)—are also becoming a core part of the development process. This is as it always should have been. It is far easier to fix a security flaw (or any flaw) at the design/early code stage than in a testing process after deployment. The quality of security testing inputs is also increasing, making it far more viable. And finally, the tools are being effectively integrated. Being a developer who did a lot of security work because we often needed it and had no one to do it, I will say I get a little rush about being told right in my IDE about the security risks in my code. I write, I see, I revise where necessary, and I turn out better code. All without having to pause for security or bang heads over policy.

    To date, all this testing is separate, but I suspect, having vaguely the same location in the process of development, that testing will all occur together and the markets may even start to merge a bit—though merger of security testing and functional/performance testing tools is a bit of a stretch, it is more possible than in the past. In most orgs, even though developers have an increasing stake in both sets of testing, the target purchasers are still two different groups—security versus test—with different priorities. That’s why I think they aren’t likely to merge any time soon.

    While AI in most technology spaces is currently experiencing the same level of FUD as XML, Java, JavaScript or low-code was in the past, all super-hyped tools in tech do have a sweet spot. Security and testing are in that sweet spot for AI. Both in test generation and in results evaluation, it does it better, faster and with more coverage while giving staff a concrete set of results to pore over and improve security posture and/or code quality. I cannot say loudly enough that in terms of enabling the steps in the SDLC that have suffered from a lack of resources and timeline to write, execute and evaluate tests, AI is a game-changer.

    So, all of these things together mean that 2024 is a good time to take a hard look at your testing environment(s) and architecture, both traditional testing and security testing. Now that AI has made advanced automation a fact, it is time to consider implementing the level of testing we always knew we should have but never had the resources. Build it right into the build process and make it part of the organizational DNA—just like Agile is.

    If you could hire a specialist who would paw through your code and give you a list of the 25 things you need to fix first, you would do it. That is, essentially, what modern testing tools are. They can do more tests, evaluate more issues and side effects and filter down to the “No—this is really important!” list without costing the team a ton of time.

    And keep rocking it. We’re all sitting on bugs and vulnerabilities. I do hope we are way past denying that fact. Apps are big old complex monsters; these days, sometimes built from generations of technologies cobbled together. Of course they have issues. Even yours. So let’s take steps to clean it up, just a little bit. And keep clipping along.

  • Fortifying the Castle: A Quest to Secure the SDLC

    Fortifying the Castle: A Quest to Secure the SDLC

    Every business is a software business today. But as the pressure to churn out new applications and features grows, so do the chances of developers making mistakes. Tackling these challenges doesn’t just require more diligent developers, it requires continuous education across the software development life cycle (SDLC).

    To borrow a metaphor from Arthurian legend, it’s a never-ending battle against hidden risks and formidable adversaries. It will require security champions to share their wisdom and bring order to the kingdom.

    A Kingdom Under Siege

    These are dark times for those fighting the good fight. The threat landscape is a wild and unruly place where risk is everywhere, and adversaries often have the upper hand. They have the advantage of surprise and are masters at hiding in the shadows. But the threat is real. One vendor blocked over 146 billion threats last year alone.

    Many of these attacks take advantage of vulnerabilities in code. It’s a problem made more acute by the widespread use of open source components by today’s developer teams. One estimate suggested that last year alone, developers made 3.1 trillion requests for these components from the top four open source ecosystems. Yet many of these components contain vulnerabilities. According to the Linux Foundation, the average application development project features 49 vulnerabilities across 80 direct dependencies. Worse are the indirect dependencies that are far harder to track and, by some estimates, account for six in every seven project vulnerabilities.

    That makes software supply chain attacks and breaches far more likely, especially as threat actors are actively placing buggy components in upstream libraries with the hope they’ll be downloaded en masse. It’s also getting more likely because developers are coming under increasing pressure to deliver. It’s claimed that over half of developers handle a hundred times more code than they did a decade ago. And most are under pressure to write code faster. This increases the chance of mistakes happening, which in turn can cause significant financial and reputational damage.

    Fighting Back

    The answer to these mounting challenges has traditionally been to focus on “shifting left” or moving testing and scanning earlier in the SDLC. To ensure products are designed with security from the outset, it’s essential to follow “secure-by-design” principles. However, this is only half the picture. Scanning for vulnerabilities is certainly important, but even better is to ensure teams are building more robust code from the outset. Prevention is always cheaper and more effective than cure.

    This is where continuous secure coding education comes in. Continuous because technology and market demands are always changing. In this dynamic world full of risk, a one-and-done approach simply doesn’t cut it. Further, courses should be extended beyond the realm of the developer to every member of the SDLC team: From project management and UX specialists to QA, product management and beyond. All must share a common goal with a common responsibility to produce more secure code. Some will be security champions who share best practices with other stakeholders. But everyone must be pulling in the same direction.

    Time to Fortify the Castle

    So once the kingdom has assembled its diligent developers and security champions, what’s next? With the knowledge and skills imparted through continuous training, plus additional automated checks, real progress can be made to enhance security and resilience.

    If you’re familiar with the OWASP Top 10, you’ll recognize concerns such as server-side request forgery, misconfiguration, using vulnerable components and shortcomings in security logging, cryptography and software integrity. A stronger focus on foundational security practices like the principle of least privilege, separation of concerns and layered defense can mitigate these risks. Among the most prevalent threats are injection attacks, which include SQL injection and cross-site scripting. However, by using tools and having developers well-versed in strategies like input validation, parameterized queries, data cleansing and secure LDAP queries, these threats can be effectively addressed.

    Above all, it’s important to remember that everyone has a part to play in fortifying the castle, in protecting the kingdom from a mounting and formidable agglomeration of threats. That means, as a baseline, that everyone should be getting some form of continuous secure coding training. There’s no time to waste.