Abstract
My technical capstone and my STS research paper both deal with risks created by
complex software systems, but at different levels. In my capstone report, I worked on securing an
internal calendar application at Freddie Mac by remediating open source vulnerabilities and
stabilizing its deployment pipeline. In my STS research, I analyzed Amazon’s experimental AI
hiring tool through the lens of care ethics to show how data driven systems can discriminate
against women applicants when engineers fail to attend to their vulnerabilities. Together, these
projects showed me that technical choices about data, dependencies, and infrastructure are tightly
connected to questions of responsibility, trust, and harm.
In the technical project, I focused on a cloud native calendar UI that had accumulated
outdated Angular and Node.js dependencies. Security scans were failing, revealing
vulnerabilities that could expose the organization to cyber attacks and regulatory issues. My
work centered on identifying vulnerable third party libraries, planning safe upgrade paths,
updating the codebase to work with newer versions, and pushing changes through Jenkins
pipelines into an Amazon EKS cluster. I monitored how the calendar microservice behaved at
runtime so I could catch issues after each deployment. The project turned a neglected component
into a hardened, maintainable service and showed how quickly technical debt can become a
serious organizational risk if engineers do not actively maintain the systems they deploy.
My STS research paper began from a different kind of risk: not a security hole, but the
way an AI system can embed discrimination into hiring. I examined Amazon’s AI hiring tool and
argued that it was deficient when viewed through care ethics. Training on male dominated
historical data, failing to proactively check how the model treated women associated signals, and
reacting to bias only after obvious problems emerged all reflected a lack of attentiveness to
women applicants as vulnerable stakeholders. I also showed how responsibility for protecting
those applicants was diffused across recruiters, engineers, managers, and executives, so no one
role was clearly charged with caring for their interests. Even when bias was discovered, the
response focused on fixing or shelving the tool rather than learning from women’s experiences or
redesigning practices to prevent similar harms in future systems.
Working on these projects at the same time changed how I understand responsible
software engineering. The capstone work gave me practical experience with securing and
operating real systems, while the STS project made me ask who is affected when those systems
fail or when they are designed without attention to vulnerable groups. It convinced me that
caring about “users” cannot only mean keeping services up and data safe; it also means asking
who is represented in the data, who is left out, and who might be quietly disadvantaged by design
choices that seem purely technical. Going forward, I hope to integrate these insights by treating
security, maintenance, and fairness as core parts of my engineering practice, building in early
reflection on stakeholders’ vulnerabilities and clear structures of responsibility rather than
waiting for a crisis to force those lessons on the team.
