It could be months before investigators figure out what happened to Russia’s robotic probe in the critical moments as it maneuvered above the lunar surface.

Yuri Borisov, Director General of Russia’s space agency, Roscosmos, blamed a botched engine burn for the disaster. He said a planned 84-second engine burn that was supposed to put the probe into a “pre-landing orbit”, instead ran for 127 seconds. 

The mission was Russia’s first since 1976, when the Soviet Union lofted Luna-24 toward Earth’s nearest neighbour. Borisov said failure to carry forward institutional knowledge from the earlier mission contributed to the Luna-25 outcome.

“The negative experience of interrupting the lunar program for almost 50 years is the main reason for the failures,” he said. “The priceless experience that our predecessors earned in the 1960-70s was effectively lost. The link between generations has been cut.”

Given the Russian government’s traditionally fraught relationship with truth and transparency, we may never learn the actual cause.

THE INVASION RIPPLE EFFECT

Truthiness in Vladimir Putin’s Russia notwithstanding, even a cursory examination of the mission highlights clear issues with development timelines and resourcing. Global sanctions imposed on Russia following its February 2022 invasion of Ukraine severely hampered mission planners as they finalized and ground-tested the vehicle. Component shortages hampered progress as engineers scrambled to implement workarounds.

The original design of Luna-25 was supposed to include a landing camera from the European Space Agency (ESA). But the ESA ended its partnership with Roscosmos after the invasion and ordered the Russians to delete their equipment from the vehicle. Technology transfer restrictions imposed on Russia also prevented it from buying a critical navigation unit from Airbus, forcing Roscosmos to develop a homegrown unit twice as heavy as the original.

Tight timelines didn’t help. Natan Eismont, a researcher with the Institute for State Research in Moscow, told the state RIA Novosti agency despite equipment problems that dogged the project all along, Roscosmos refused to delay the launch. Russian space blogger Vitaly Egorov said Russia wanted to land before Chandrayaan-3.

“It looks like things weren’t going according to plan,” he said, “but they decided not to change the schedule to prevent the Indians from coming in first,”

Luna-25’s failure echoed that of the ill-starred Phobos-Grunt sample return mission in 2011 that was supposed to explore the Mars moon Phobos. Instead, the earlier mission failed to execute a critical burn in Earth orbit and crashed back into the Pacific. Investigators blamed the use of off-the-shelf microchips that couldn’t stand up to the radiation and heat extremes of space.

KEY TAKEAWAYS FOR DEVELOPERS

Russian opaqueness and troubling history notwithstanding, the Luna-25 narrative is already informing developers both inside – and far beyond – the space industry. Developers in particular might want to keep the following critical lessons in mind:

1. Be flexible on timing. On-time delivery of complex projects is always a challenge, and rigid adherence to a timeline is decidedly not always the way to go. By forcing engineers to stick to the original schedule despite ongoing component shortages and redesigns, Luna-25’s leadership forced compromises that resulted in a flawed vehicle that was unfit for the mission. Extra time might have allowed these gaps to be addressed, but we’ll never know now.
2. Don’t skimp on testing. Whatever scenario Luna-25 encountered that caused its engine to fire for 50% longer than planned, it’s clear the in-development testing regime failed to account for everything that could happen in flight. It may seem like a quick way to prevent the timeline from slipping to the right, but skimping on testing and simulation adds huge risk to any project. This applies not only in the harsh environment of space, but even within the most mundane software development projects.
3. Focus on error handling. As systems become increasingly automated, their ability to autonomously – and gracefully – recover from unexpected events becomes ever more critical to successful final outcomes. Robust, clean, elegant code sets the stage for systems that adapt to uncertainty – both in-orbit and back on Earth.
4. Document in parallel. The admission by Roscosmos’s leader that they didn’t learn from earlier missions is a troubling one that fails to honour Russia’s storied space history. Proper documentation – performed in lockstep with project execution – can go a long way toward preserving institutional knowledge and ensuring it remains accessible to developers for future projects.
5. Learn from every mistake. Chandrayaan-3’s successful landing comes less than 4 years since the Vikram lander separated from the Chandrayaan-2 orbiter and crashed into the Moon while attempting to land on the south pole. The Indian Space Research Organization (ISRO) launched a public inquiry, and folded learnings directly into the Chandrayaan-3 mission.

THE BOTTOM LINE

Every project now depends to a certain degree on software – and this is just as true down here on terra firma as it is in outer space. Whether you’re a space-nerd or not, the lessons from Luna-25’s failure and Chandrayaan-3’s success should give you cause to reflect on your own development experiences.

In the meantime, we’re working on an exciting new platform that will also help inform your future development experiences. We call it the StringNetwork, and you can sign up here to learn more.

The post Luna-25 and Chandrayaan-3 tell two very different stories for developers first appeared on STEP Software.

In essence, DevSecOps is a refinement of the original DevOps concept that puts more emphasis on the importance of application security. Many cybersecurity incidents are the result of security flaws in an application’s code. There is a strong argument that the DevOps movement’s focus on faster software deployment acts as a barrier to developing secure software.

Software security teams are tasked with ensuring that vulnerable code is not released into production. Traditionally, security teams implement rigorous testing to verify the integrity and security of applications. However, security testing takes up valuable time, and time is of the essence in DevOps teams. There is a clear conflict between the goals of security teams and the ideals of the DevOps movement.

Security tests and checks are carried out at the end of development cycles in DevOps, however, there is often simply not enough time to properly audit code. The DevSecOps movement advocates embedding security practices and tools in the design of an application. In DevSecOps, security requirements are considered from the outset, which helps to better ensure watertight software security.

DevSecOps Best Practices

There are several opportunities to ingrain security into the workflows of DevOps teams. The general goal is that software security requirements should be met without compromising the fluidity and speed inherent in DevOps development cycles. Consider the following best practices for achieving alignment with a DevSecOps mindset.

Security Test Automation

Automation is a vital aspect of the DevOps philosophy because it speeds up development by automating repetitive tasks. Security teams can speed up their testing through increased automation, and it is prudent to introduce these tests as early as possible in each development cycle.

Emphasize Supply Chain Security 

A number of high-profile cybersecurity incidents in recent years have arisen due to open source vulnerabilities. Developers often use libraries and frameworks from open source projects as part of the development of applications. The infamous Equifax data breach occurred as a result of using a vulnerable version of the open-source Apache Struts web framework.

Security teams must create policies that emphasize software supply chain security. Developers need to be encouraged to properly source the libraries and frameworks they use. Patches should be applied as soon as possible, and build automation tools can provide visibility into vulnerable software components that require patching.

Facilitate Speed and Precision

Security teams need to remember that heir tests and checks must be completed both quickly and accurately. Security tools suited for DevOps teams would ideally be able to identify vulnerable code as it is being written because this facilitates immediate action to rectify those vulnerabilities.

Train Developers in Application Security

A surprisingly high number of developers are never taught how to securely code software. Third-level computer science courses typically emphasize the logistics of programming and instruct developers on how to build functional code.

Infosec teams need to convince stakeholders at organizations to invest in training for developers on application security. Security teams could run these courses, and they would equip developers with a level of knowledge that would lead to long-term benefits in achieving a secure DevOps culture.

The Time for DevSecOps is Now

DevSecOps is a crucial evolution in the DevOps movement. Make sure everyone at your organization understands the costs and risks of releasing vulnerable software into production. Make changes to embed security into DevOps teams and leverage some of the aforementioned best practices.

The post DevSecOps: Why It’s Important and How To Achieve It first appeared on STEP Software.