Introduction Introduction When Yoda mentioned the famous words to a struggling and young Luke Sykwalker on the marshy world of Dagobah, he wasn’t teaching Luke about the power of Telekinesis. It was a lesson on “commitment.” No half-hearted attempts at anything. Providing reliable and secure software today demands that approach and mindset. Most teams at many organizations, whether large or small, often consider security to be an afterthought. They focus on “trying” to inject it within the software development lifecycle. They “try” to fix a vulnerability if there is additional time before a tight release schedule; they “try” to know about the latest threats in the planning phase. But in today’s rapidly evolving technology landscape, securing the SDLC, in an end-to-end manner, cannot be overlooked; simply “trying” without a thought-out plan and an actionable approach toward execution can result in major security breaches down the line for any organization, whether a large multinational or a small nonprofit. As an example, the famous breach of customer information in Equifax, around 2017, is a stark reminder that even large organizations can miss out on fixing a simple patch, and this can lead to the exposure of sensitive data of 147 million customers [1]. In my experience working collaboratively with several SMBs and nonprofits, I have learned how they can secure themselves with highly effective open-source tools so that they can protect themselves against cyber-attacks and secure their SDLC without breaking the bank. The Force Awakens: Understanding Security in SDLC The Force Awakens: Understanding Security in SDLC Considering security a second-class citizen can lead to bottlenecks. The traditional approach has always focused on security at the later phases of SDLC. The approach of “Shifting Left” and incorporating elements of security in the initial stages such as planning, requirements gathering, architecture design/build is crucial. Developers want to operate at speed and ship features quickly whereas security teams want safety. This results in both the teams often clashing with each other. However, the rule of ten in software engineering states that a bug that is caught early in the SDLC phase would cost way less than a bug caught in the design phase or worse: the production phase [2]. Research shows that approximately 80% of the systems penetrations occurring in commercial software are due to errors during the coding phase [3]. As a result, security is not just a plugin or an optional feature. It is a “continuous force” that flows tightly through each line of code before every reaching any architectural decision or build phase. In this situation, being reactive always means that you’re always playing catchup, rather than focusing on designing a system that consistently stops attacks at scale. Lastly, cyber-attacks have usually been the headache of large multinational corporations. However, nonprofits are also seeing an increasing uptick in the number of cyber-attacks [4].  Attackers generally exploit the limited financial and technical capabilities of nonprofits. Sophisticated phishing and campaigns attacks targeting donor data and information is a major area of interest for adversaries. Phase-wise Security Integration Phase-wise Security Integration What does it truly mean to “do” and infuse security into every phase of the SDLC without breaking the bank, specifically for nonprofits? Security should not be added as an extra layer at the end; it requires a shift of mindset, and it should touch every aspect of SDLC from requirements to operations and maintenance. Phase 1: Requirements Gathering & Analysis Phase 1: Requirements Gathering & Analysis First and foremost, security ought to begin with the definition of done. If we do not map out and define what exactly we mean by a “secure” system, it would be very difficult for us to build it out later. During the requirements gathering and analysis phase, it is crucial to identify both functional as well as non-functional security requirements of the software being developed. OWASP Threat Dragon or Pytm tool can be used to map out the data flows within the technical stack of an organization and model potential threats. Further, OCR capabilities of ChatGPT or Google Gemini can be used to extract information from architecture diagrams and that can be fed into the model once again to create attack trees or list potential attack vectors for a threat modelling exercise. Phase 2: Design Phase Phase 2: Design Phase A secure design phase can make sure that the unforeseen errors are avoided in the SDLC, making this a very crucial stage for budling long term resilience in any software product. Smaller firms can use free tools such as Draw.io to build out security templates. These templates can be used to map out trust boundaries and visualize how data flows through the different systems. Another free threat modeling tool, the community edition of IriusRisk can be used to model systems [5]. If a startup has few APIs that lack rate limiting requirements, the tool can assist in identifying that. Further, new tools leveraging LLMs such as STRIDE GPT can be used to chart attack trees and design threat models using the STRIDE framework [6]. Phase 3: Development & Coding Phase 3: Development & Coding As we discussed earlier, the coding phase is wherein most of the software vulnerabilities are introduced. Hence, it is imperative that this phase is looked at very carefully to prevent any critical flaws seeping into the software. Secure coding standards, such as those popularized by OWASP Top 10 are a must have [7]. NIST also provides free resources of Secure Software Development Framework (SSDF) providing organizations with an outcome focused security action plan [8]. Tools such as Semgrep and Horusec can be used to find out compliance issues with the written code or identify bad coding practices across a broad scope of issue like hardcoded passwords, insecure API calls, or outdated dependencies in real time. Additionally, if a configuration file has an AWS secret key, that can be detected by another open-source tool Gitleaks [9]. Phase 4: Testing & Quality Assurance Phase 4: Testing & Quality Assurance Once the development is complete, we can move forward to the testing and QA phase. This is where the entire code gets battle tested. From static analysis to dynamic testing, there are various approaches to find out weaknesses in this phase. Tools like OWASP ZAP (by Checkmarx) can provide automated baseline scans with respect to staging environments [10]. Another tool Nuclei can be leveraged to misconfigurations or insecure endpoints [11]. Phase 5: Deployment & Release Phase 5: Deployment & Release Deployment is the phase when the ship has finally left the hangar to say the least. The shields must be up, and the configurations should be verified. For organizations using cloud platforms, tools such as Trivy can scan the Docker images for vulnerabilities [12]. In addition, Checkov can be used to identify misconfigured cloud resources using Terraform scripts [13]. As an example, consider a team is deploying a microservice. Trivy would flag the base docker image that has a high-severity vulnerability. The team can then swap it for a “distroless” version, which would reduce the attack surface area. These sorts of checks can be worked out in the deployment phase. Phase 6: Maintenance & Monitoring Phase 6: Maintenance & Monitoring The road toward building a secure software doesn’t end at shipping the features and calling it a day. New threats emerge almost daily. In this regard, continuous monitoring is essential to manage the overall security posture of an organization. Free tools such as Wazuh can be useful in providing host-based intrusion detection and system monitoring [14]. It can be coupled with insights from OpenVAS to perform regular vulnerability scans of networks and servers [15]. Lastly, another tool, HashiCorp Vault is a useful secrets management and data protection tool. It can be used to audit access logs for compliance or rotate secrets automatically [16]. From a policy and compliance standpoint, Eramba can be used to manage risk frameworks and internal GRC controls [17]. In recent news, Clawdbot, an AI agent, has become a viral sensation. It can be used to automate tasks and extend workflows, while interacting with APIs and executing various commands autonomously [18]. Conclusion, Key Takeaways & Call to Action Conclusion, Key Takeaways & Call to Action It is very important that security is considered a key driver for ensuring reliable, lasting software. The entire process must be intentional and continuous. Every phase of the SDLC provides an opportunity to prevent vulnerabilities. The open source and free tools listed above are very practical and cost-effective ways for smaller organizations and nonprofits to secure themselves without stretching their budgets. The call to action is very simple – let’s stop “trying” to secure our software and commit fully and wholeheartedly to this endeavor. Rather than checking boxes for the sake of security, let’s not put half baked attempts at securing the SDLC phases. Remember as Yoda said - Do or do not. There is no try. References References [1] https://www.cnbc.com/2019/07/22/what-you-need-to-know-equifax-data-breach-700-million-settlement.html https://www.cnbc.com/2019/07/22/what-you-need-to-know-equifax-data-breach-700-million-settlement.html [2] https://www.code-intelligence.com/blog/rule-of-ten https://www.code-intelligence.com/blog/rule-of-ten [3] https://www.sciencedirect.com/science/article/abs/pii/S1361372311700835 https://www.sciencedirect.com/science/article/abs/pii/S1361372311700835 [4] https://www.infosecurity-magazine.com/news/nonprofits-email-threats-rise-35/ https://www.infosecurity-magazine.com/news/nonprofits-email-threats-rise-35/ [5] https://www.iriusrisk.com/community https://www.iriusrisk.com/community [6] https://github.com/mrwadams/stride-gpt https://github.com/mrwadams/stride-gpt [7] https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/ https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/ [8] https://csrc.nist.gov/projects/ssdf https://csrc.nist.gov/projects/ssdf [9] https://github.com/gitleaks/gitleaks https://github.com/gitleaks/gitleaks [10] https://www.zaproxy.org/ https://www.zaproxy.org/ [11] https://github.com/projectdiscovery/nuclei https://github.com/projectdiscovery/nuclei [12] https://trivy.dev/ https://trivy.dev/ [13] https://www.checkov.io/ https://www.checkov.io/ [14] https://wazuh.com/ https://wazuh.com/ [15] https://www.openvas.org/ https://www.openvas.org/ [16] https://github.com/hashicorp/vault https://github.com/hashicorp/vault [17] https://www.eramba.org/ https://www.eramba.org/ [18] https://www.cnet.com/tech/services-and-software/from-clawdbot-to-moltbot-to-openclaw/ https://www.cnet.com/tech/services-and-software/from-clawdbot-to-moltbot-to-openclaw/

Terra

The Secure Force: Building an End-to-End SDLC Without Breaking the Bank

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

From SaaS to AI Agents: Are We Entering a New Software Era?

108 Stories To Learn About Cybersecurity Tips

10 Ways to Mitigate Cybersecurity Risks and Prevent Data Theft

10 Tips For Securing Zoom Meetings

10 Things I Did To Increase CloudTrail Logs Security

10 Steps to Ensuring Cyber Security for a Small Business

From SaaS to AI Agents: Are We Entering a New Software Era?

108 Stories To Learn About Cybersecurity Tips

10 Ways to Mitigate Cybersecurity Risks and Prevent Data Theft

10 Tips For Securing Zoom Meetings

10 Things I Did To Increase CloudTrail Logs Security

10 Steps to Ensuring Cyber Security for a Small Business

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps